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.
As preparation for #125945.
The PR improves tests itself which allows the `arc` method to be available to check whether corresponding rects are drawn during tests.
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.
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 :)
toDart exists on the latter, not the former.
Fixing https://github.com/flutter/flutter/pull/125220.
## Pre-launch Checklist
- [x] I read the [Contributor Guide] and followed the process outlined
there for submitting PRs.
- [x] I read the [Tree Hygiene] wiki page, which explains my
responsibilities.
- [x] I read and followed the [Flutter Style Guide], including [Features
we expect every widget to implement].
- [x] I signed the [CLA].
- [x] I listed at least one issue that this PR fixes in the description
above.
- [x] I updated/added relevant documentation (doc comments with `///`).
- [x] I added new tests to check the change I am making, or this PR is
[test-exempt].
- [x] All existing and new tests are passing.
Types are being reified in the JS backends, so these need to be
addressed. Fixes two issues:
- @staticInterop types need to be casted to JS types
- JS functions need to be cast to JSFunction before conversion
Enables landing of https://dart-review.googlesource.com/c/sdk/+/295105.
## Pre-launch Checklist
- [X] I read the [Contributor Guide] and followed the process outlined
there for submitting PRs.
- [X] I read the [Tree Hygiene] wiki page, which explains my
responsibilities.
- [X] I read and followed the [Flutter Style Guide], including [Features
we expect every widget to implement].
- [X] I signed the [CLA].
- [X] I listed at least one issue that this PR fixes in the description
above.
- [X] I updated/added relevant documentation (doc comments with `///`).
- [X] I added new tests to check the change I am making, or this PR is
[test-exempt].
- [x] All existing and new tests are passing.
Related https://github.com/flutter/flutter/issues/100624
The goal is to make sure the engine can send a location string in either the existing format or a complete uri string to the framework, and the framework will still work as usual.
Include rects with any overlap instead of only when top-left or bottom-right included. The previous criteria didn't send any selection rects when text was taller than the text box and scroll offset was not zero.
Part of #30476
