fixes https://github.com/flutter/flutter/issues/126679
### Description
Control cupertino widgets like `CupertinoCheckbox` and `CupertinoRadio` have `focusNode` and `autofocus`, while these are missing in `CupertinoSwitch`.
This is blocking https://github.com/flutter/flutter/issues/126637
(`switch.dart` currently maintains its focus node for `CupertinoSwitch` when using `Switch.adaptive` which causes a bug)
fixes https://github.com/flutter/flutter/issues/126397
The `parseCompactDate` method in `material_localizations.dart` with long text throws an argument error before the date picker could handle it to show a validation error while the date picker is on autovalidate.
This PR adds `try/catch` in the `parseCompactDate` to return null on the argument error.
Fixes https://github.com/flutter/flutter/issues/126454.
In certain situations (see linked bug) the Scrollable needs access to the DPR of the View it is drawn into during disposal. Since inherited widget lookups are not allowed during disposal, we cannot look up the DPR dynamically in these situations. Instead, we have to cache the DPR when lookups are still allowed.
Sync lints with https://github.com/dart-lang/linter/blob/master/example/all.yaml and enable `implicit_reopen` and `type_literal_in_constant_pattern` (which have no violations). Also contains some clean-up work towards enabling `matching_super_parameters`, which is not quite ready yet due to its handling of "private" arguments.
Fixes#122250. This PR is to make sure all the MaterialStateProperty defaults are able to correctly resolve different states.
* When a widget is pressed, it is also hovered, so we need to put the `MaterialState.pressed` check before `MaterialState.hovered`.
* When a widget is focused, the widget should still be able to be hovered, so we should check `MaterialState.hovered` before `MaterialState.focused`.
* There are also cases like in _InputDecoratorDefaultsM3, the `MaterialState.disabled` should be checked before `MaterialState.error`.
the order should be disabled, (error), pressed, hovered, focused.
## Description
This PR adds some details in FocusNode documentation to explain more precisely when listeners are notified.
## Related Issue
Fixes https://github.com/flutter/flutter/issues/126149
## Tests
Documentation only.
Close https://github.com/flutter/flutter/issues/125724
> The `navigator.dart` has ~10 repeats of things like:
>
> ```dart
> final _RouteEntry? currentRouteEntry = _navigator!._history.cast<_RouteEntry?>().lastWhere(
> (_RouteEntry? e) => e != null && _RouteEntry.isPresentPredicate(e),
> orElse: () => null,
> );
> ```
>
> while it can be greatly simplified as:
>
> ```dart
> final _RouteEntry? currentRouteEntry = _navigator!._history.lastWhereOrNull(_RouteEntry.isPresentPredicate);
> ```
>
> Thus, it seems that we can beautify the code a little bit.
Same as https://github.com/flutter/flutter/pull/125099, but without external dependency
For more detailed explanation why it does not introduce external dependency: https://github.com/flutter/flutter/pull/125099#discussion_r1174230502
This PR adds a month and year mode to the CupertinoDatePicker. The monthYear mode is the date mode without the day of the month.
This feature was added at the request of:
[Proposal] CupertinoDatePicker with month and year. #93508
One thing that I was unsure of was the use of the DatePickerDateOrder to determine the monthYear order. It could be considered a workaround since the DatePickerDateOrder is intended to order day, month, and year. This means that a developer could use the DatePickerDateOrder.dmy (day, month, year) or DatePickerDateOrder.mdy (month, day, year) to get the same result.
At first I intended to add a DatePickerMonthYearOrder enum to the localizations, in addition to a new parameter for the CupertinoDatePicker for monthYearOrder, but I ended up reverting these changes (1c61f1084e) because I had not considered the effects of adding values to the localizations.
I decided it may be better to not add an additional parameter (monthYearOrder) that would go mostly unused. I am very open to feedback or ideas on this matter.
This PR contains a series of minor changes to address issues that I happened to run into:
- Pretty-print errors triggered when handling events that are pending because of having locked event handling. Previously these were just dumped to the console.
- Add more documentation for `debugPaintPadding`.
- Add documentation to `Tween` saying how to implement it.
- Slight formatting changes in the scrollbar code to align some expressions.
- Since we convert ScrollMetricsNotifications to ScrollNotifications in various places, provide an explicit API to do this. This will make the behaviour consistent throughout, and makes the code easier to understand. Added a test for this.
- Clarifications to some of the BindingBase and SchedulerBinding documentation.
- Clarified some documentation in `flutter_test`'s `Finder` class.
The property was typed as nullable, but the code assumed its always non-null. This makes the property non-nullable as well.
Also refactors CupertinoListSection, which was flagged by the analyzer when borderRadius became non-nullable (no functional change, just cleaning up existing code to avoid the warning).
I'd like to find out the `fontSize` of a `PlaceholderSpan`, and currently there doesn't seem to be a way to do `TextStyle` cascading in the framework:
`InlineSpan.visitChildren` traverses the entire `InlineSpan` tree using a preorder traversal, and nodes that don't have "content" will be skipped (https://master-api.flutter.dev/flutter/painting/InlineSpan/visitChildren.html):
> Walks this [InlineSpan](https://master-api.flutter.dev/flutter/painting/InlineSpan-class.html) and any descendants in pre-order and calls visitor for each span that has content.
which makes it impossible to do `TextStyle` cascading in the framework:
- `InlineSpan`s with a non-null `TextStyle` but has no content will be skipped
- `visitChildren` doesn't directly expose the hierarchy, it only gives information about the flattened tree.
This doesn't look like a breaking change, most internal customers are extending `WidgetSpan` which has a concrete implementation of the new method.
Alternatively I could create a fake `ui.ParagraphBuilder` and record the `ui.TextStyle` at the top of the stack when `addPlaceholder` is called. But `ui.TextStyle` properties are not exposed to the framework.
Close#125385 - please see explanations there :)
If you think this PR looks OK, I will polish it (e.g. copy-and-paste-and-modify the tests shown in #125385 into here and make CI pass)
Engine PR: https://github.com/flutter/engine/pull/41593
This must land first
We should remove these, as they've been deprecated for a while. On the engine side of things, the physical model layer is the only one which requires the device pixel ratio, so deleting it will allow us to simplify the layer tree code in https://github.com/flutter/engine/pull/41559
## Description
This PR adds a new debug flag named `debugPrintKeyboardEvents` to help debugging keyboard issues.
Keyboard code has some useful asserts but sometimes an assertion failure is related to the handling of previous key events. This debug flag will help understanding the flow of key events which leads to an assertion failure.
## Related Issue
Fixes https://github.com/flutter/flutter/issues/125627
## Tests
Adds 1 test.
cc'ing existing conversation participants: @domesticmouse @srawlins
cc'ing to request review: @goderbauer
This PR makes the following constructor arguments required:
1. `FutureBuilder.future`
2. `StreamBuilderBase.stream`
3. `StreamBuilder.stream`
This fixes:
https://github.com/flutter/flutter/issues/83081https://github.com/flutter/flutter/issues/125188 (dupe of 83081)
This obviates:
https://github.com/dart-lang/linter/issues/4309
(I suggest we skip straight to merging this PR as this should be a low impact breaking change-assuming few to no devs are intentionally using the builders without their relevant arguments, however we could always merge 4309 first and then this)
https://github.com/flutter/flutter/pull/83101
(The above PR required that at least one of future and initial data be non-null, this is undesirable as there are plenty of valid reasons to have both arguments be null)
See above issues for a deeper dive, but here is a summary:
It is very easy for a developer to forget to specify `future` or `stream` when using the respective `*Builder` widgets. This produces a non-obvious failure where the UI sits in a "no data yet received" state. It is easy for a dev to misinterpret this as the async work backing the future/stream hanging and they thus waste a lot of time trying to debug the async work.
As such, we should require these two constructor arguments to make it impossible/much harder for devs to make this time-wasting mistake.
This is a breaking change. However, it should break only a small number of active projects given that using a builder without specifying `future` or `stream` seems highly niche.
The only place I've found non-accidental examples of this is in widget tests where you're calling `pumpWidget` with and without these arguments to test `*Builder.didUpdateWidget`'s behavior. In this and similar cases, it is a trivial fix to add `future: null`/`stream: null`.
*If you had to change anything in the [flutter/tests] repo, include a link to the migration guide as per the [breaking change policy].*
We were failing to dispose of animation controllers created by `animateTo` when `didUpdateWidget` happens and we null out the `_attachedController`. This would cause the listener added here to fail on a null assertion:
fef41cfce0/packages/flutter/lib/src/widgets/draggable_scrollable_sheet.dart (L135)
Without the code change, the test ends up throwing exceptions related to that line. I don't have a great way to verify what this does visually though, hoping for help on that from internal customer.
b/279930163
See cl/527868355 as well.
Fixes https://github.com/flutter/flutter/issues/125709
Background: I am adding logging to things like dialogs, bottom sheets and menus. Then I realized that, showMenu does not allow users to provide RouteSettings, while showDialog and showModalBottomSheet both allow. Therefore, IMHO a consistent API design may need to add this to showMenu.
I will add tests if this proposal looks OK :)
