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.
Just a one-word super tiny change, which I encounter today when playing with RawGestureDetector :)
The original doc says:
> For common gestures, use a [GestureRecognizer](https://api.flutter.dev/flutter/gestures/GestureRecognizer-class.html). [RawGestureDetector](https://api.flutter.dev/flutter/widgets/RawGestureDetector-class.html) is useful primarily when developing your own gesture recognizers.
However, for "common gestures", IMHO the doc wants to say `GestureDetector` (because that one has easy-to-use onTap, onLongPress etc). On the other hand, GestureRecognizer should be used together with RawGestureDetector and is a quite low-level thing, and for common gestures people seldom use it. So I guess here it is a typo.
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
In the specific implementation, the Divider uses the "space" field as the height for horizontal dividers, and the "space" field as the width for VerticalDivider , which is different from the documentation description.
#125151 introduced the magnifier on touch drag gestures, but when showing the magnifier the toolbar is implicitly hidden, this change makes the toolbar re-appear on drag end for double tap + drag.
