This changes how the `IconThemeData` is passed to the child of `CupertinoButton`.
Previously, it would derive the foreground color from the current theme and create a new `IconThemeData` object.
This causes any `IconThemeData` to be overwritten.
This change uses `IconTheme.of` to get the currently applied icon theme and only overwrites the properties provided by the `CupertinoButton` instead of the whole object.
Fixes#149172.
MenuAnchor for Material 3 is great for contextual menus but there are some minor issues related to accessibility.
This PR aims to close the gap by adding `autofocus` to the menu item button so keyboard navigation is more intuitive. Otherwise, it becomes a mess to navigate through just keyboards.
Partially resolves#139395
## Additional Notes
I should mention, I have not written tests for this due to it's trivial nature. I also lack the experience of writing Flutter tests in general, so if someone feels inclined to take over this PR and add it they're welcome to.
Part of https://github.com/flutter/flutter/issues/150800.
I turned on the `comment_references` lint and looked at what needed fixing inside of the `animation` library.
There are a couple of places where for some reason adding a docImport didn't fix the `comment_references` warning:
## Description
This PR sets a minimal height for collapsed `InputDecoration`.
Before this PR the minimum height was 0. On desktop, due to visual density reducing the height by 8 pixels, it leads to a collapsed text field height being too small to fit the input text vertically.
The following screenshot shows a default collapsed M3 TextField on macOS. On M3 the font style is 16px with a 1.5 height, so the input height is 24. The decoration height is 16 because of the visual density reduction (this results in the border being misplaced, some letters overflowing and the cursor overflowing).
After this PR, the minimum height is the input height.
## Related Issue
Fixes https://github.com/flutter/flutter/issues/150763
## Tests
Adds 4 tests, updates 2.
Fixes part of #150524.
Recently I was studying RenderObject and related code to understand
how the rendering library tracks which objects need layout, and in
particular just how the concept of "relayout boundary" works.
The [RenderObject._relayoutBoundary] property itself had no docs,
and there were some other areas that I felt could be clearer;
so here's a PR where I add those docs.
In addition to docs, this makes some small pure refactors. Mostly
those are in order to make clear docs easier to write. One rename
is to fix a lone straggler from #4425 / #4483.
One key thing I learned, which this documents, is an invariant that
this code maintains on [_relayoutBoundary]. With that invariant in
mind, I found it's possible to simplify that bookkeeping, and to get a
measurable performance improvement as a bonus. To keep things simple,
though, I'll leave those for follow-up PRs.
For ease of review, the PR is broken into several commits each with
their own commit message.
fix typo
*List which issues are fixed by this PR. You must list at least one issue. An issue is not required if the PR fixes something trivial like a typo.*
*If you had to change anything in the [flutter/tests] repo, include a link to the migration guide as per the [breaking change policy].*
Fix a link in the `RenderObjectWidget` doc comment. The comment recommends subclassing `SingleChildRenderObjectElement` where it means to recommend subclassing `SingleChildRenderObjectWidget`.
Fixes#150597.
This PR fixes the general layout of `CupertinoActionSheet` to match the native behavior.
This PR adjusts the height of buttons, the height of the content section, the gap between the cancel button and the main sheet, and most importantly, the maximum height of the action sheet.
The maximum height is the trickiest part. I tried to figure out a rule, and found that the top padding only depends the type of the device - notch-less, notch, capsule - but there isn't a clear rule that can unify the 3 padding numbers. This PR uses linear interpolation as a heuristic algorithm. See the in-code comment for details.
* What about iPad? Well, action sheets look completely different on iPad, more similar to a drop down menu. This might be fixed in the future.
### Tests
Among all the test changes, there are a few tests that have been converted to using `AnimationSheetRecorder` to verify the animation changes. Before the PR they were checking the height at each from, which is hard to reason whether a change makes sense, and hard to modify if anything needs changing.
### Result demo
The following images compares native(left) with Flutter after PR (right) by stacking them closely, and show that their layout really match almost pixel perfect.
<img width="455" alt="image" src="https://github.com/flutter/flutter/assets/1596656/f8be35bd-0da5-4908-92f7-7a1f4e999229">
_No notch (iPhone 13)_
<img width="405" alt="image" src="https://github.com/flutter/flutter/assets/1596656/54a37c2f-cd99-4e3b-86f0-045b1dfdbbb8">
_Notch (iPhone 13)_
<img width="385" alt="image" src="https://github.com/flutter/flutter/assets/1596656/546ab529-0b62-4e3d-9019-ef900d3552e5">
_Capsule (iPhone 15 Plus)_
<img width="1142" alt="image" src="https://github.com/flutter/flutter/assets/1596656/e06b6dac-dbcd-48f7-9dee-83700ae680e0">
_iPhone 13 landscape_
<img width="999" alt="image" src="https://github.com/flutter/flutter/assets/1596656/698cf530-51fc-4906-90a5-7a3ab626f489">
_All "capsule" devices share the same top padding in logical pixels (iPhone 15 Pro Max, iPhone 15 Pro, iPhone 15 Plus)_
This change enables double tap / triple tap support in SelectionArea for mobile platforms:
Android / Fuchsia:
- On native, these platforms allow for double tap / double tap + drag to select word-by-word.
- On web using touch, these platforms only support double tap to select word.
- On web and native using a mouse, these platforms support double click / double click + drag to select word-by-word, and triple click / triple click + drag to select paragraph-by-paragraph.
iOS:
- On native, these platforms allow for double tap / double tap + drag to select word-by-word.
- On web using touch, these platforms do not support double tap/triple tap gestures.
- On web using touch, these platforms allow support double tap + drag gestures.
- On web and native using a mouse, these platforms support double click / double click + drag to select word-by-word, and triple click / triple click + drag to select paragraph-by-paragraph.
Part of: https://github.com/flutter/flutter/issues/129583
Currently, when text is placed inside a SelectionArea widget that's nested within a Column widget, it results in misalignment, causing the text to appear centered instead of aligned as intended.
This was originally #149552 but had issues with my branch.
*List which issues are fixed by this PR. You must list at least one issue. An issue is not required if the PR fixes something trivial like a typo.*
Fixes#148934Fixes#121053
*If you had to change anything in the [flutter/tests] repo, include a link to the migration guide as per the [breaking change policy].*
Add tests for `InputDecoration` API example as part of #130459. Updates examples that use the deprecated MaterialState to use WidgetState. Tests files: `input_decoration.0.dart`, `input_decoration.1.dart`, `input_decoration.2.dart`, `input_decoration.3.dart`, `input_decoration.widget_state.0.dart`, `input_decoration.widget_state.1.dart`, `input_decoration.prefix_icon_constraints.0.dart`, `input_decoration.suffix_icon_constraints.0.dart`, and `input_decoration.label.0.dart`
Introducing the `forceErrorText` property to both `FormField` and `TextFormField`. With this addition, we gain the capability to trigger an error state and provide an error message without invoking the `validator` method.
While the idea of making the `Validator` method work asynchronously may be appealing, it could introduce significant complexity to our current form field implementation. Additionally, this approach might not be suitable for all developers, as discussed by @justinmc in this [comment](https://github.com/flutter/flutter/issues/56414#issuecomment-624960263).
This PR try to address this issue by adding `forceErrorText` property allowing us to force the error to the `FormField` or `TextFormField` at our own base making it possible to preform some async operations without the need for any hacks while keep the ability to check for errors if we call `formKey.currentState!.validate()`.
Here is an example:
<details> <summary>Code Example</summary>
```dart
import 'package:flutter/material.dart';
void main() {
runApp(
const MaterialApp(home: MyHomePage()),
);
}
class MyHomePage extends StatefulWidget {
const MyHomePage({
super.key,
});
@override
State<MyHomePage> createState() => _MyHomePageState();
}
class _MyHomePageState extends State<MyHomePage> {
final key = GlobalKey<FormState>();
String? forcedErrorText;
Future<void> handleValidation() async {
// simulate some async work..
await Future.delayed(const Duration(seconds: 3));
setState(() {
forcedErrorText = 'this username is not available.';
});
// wait for build to run and then check.
//
// this is not required though, as the error would already be showing.
WidgetsBinding.instance.addPostFrameCallback((_) {
print(key.currentState!.validate());
});
}
@override
Widget build(BuildContext context) {
print('build');
return Scaffold(
floatingActionButton: FloatingActionButton(onPressed: handleValidation),
body: Form(
key: key,
child: Center(
child: Column(
mainAxisAlignment: MainAxisAlignment.center,
children: [
Padding(
padding: const EdgeInsets.symmetric(horizontal: 30),
child: TextFormField(
forceErrorText: forcedErrorText,
),
),
],
),
),
),
);
}
}
```
</details>
Related to #9688 & #56414.
Happy to hear your thoughts on this.
Reverts: flutter/flutter#150386
Initiated by: andrewkolos
Reason for reverting: the Mac framework_tests_impeller check has been failing (due to golden test failures) since this PR (though it occasionally passes after retry). Taking a brief look at this PR, it looks like there's been some troubles with goldens in the past (though the recent failures appear very different to past ones). Regardless, I'm taking a shot at getting the tree green again by reverting this. Apologies i
Original PR Author: dkwingsmt
Reviewed By: {chunhtai}
This change reverts the following previous change:
Relands https://github.com/flutter/flutter/pull/149568 (first attempt) or https://github.com/flutter/flutter/pull/150129 (latest attempt), which was reverted in https://github.com/flutter/flutter/pull/150142 due to unverified golden tests post-commit from recent infra issues.
No code is changed from https://github.com/flutter/flutter/pull/150129.
The relevant golden files have been resubmitted in https://github.com/flutter/flutter/pull/150219. I expect these files to appear in the golden file checker in this PR (which will hint that this PR is safe.) Fingers crossed.
`ThemeData.ScaffoldBackgroundColor` originally defaults to `ColorScheme.background`. As background in ColorScheme is deprecated, customizing background is not able to change scaffold background color. This PR is to make `scaffoldBackgroundColor` defaults to `ColorScheme.surface` which is the replacement of `ColorScheme.background`.
Fixes https://github.com/flutter/flutter/issues/149158
Relands https://github.com/flutter/flutter/pull/149471.
As explained in https://github.com/flutter/flutter/pull/150147, the original PR was reverted in an attempt to fix the strange golden file failure that occurred in other PRs.
The following code is changed:
* The two tests that contain golden tests are changed so that, they used to slide from button 1 to button 2, now they slide from button 2 to button 1. This is to ensure the golden file record are updated.
#83531 contains complaints that this default disabled color can no longer be overridden by setting a color of the `decoration` property. This regression was introduced by #78058, which was itself made to fix an issue where the color of the decoration was always used even when disabled.
Currently, when the text field is disabled, its color is set to a default disabled color. This PR makes it so that if a decoration is set when the text field is disabled, its color is used instead of the default disabled color.
Fixes https://github.com/flutter/flutter/issues/83531
Switch away from the `Iterable.castFrom` static method to the `Iterable.cast` instance method which is more readable and more consistent with other iterable usages.
This PR just has a tiny doc change to correct the doc for `ColorScheme.surface`. Previously, Card background color defaults to `ColorScheme.surface` but we updated the default since we've introduced the new tone-based surface colors, like `surfaceContainer`, `surfaceContainerLow` and etc. The `surface` in ColorScheme should now replace deprecated `background` which is the default background color of Scaffold.
Related to the comment here: https://github.com/flutter/flutter/pull/149772#issuecomment-2157596540
