Reverts: flutter/flutter#150015
Initiated by: vashworth
Reason for reverting: Still failing tree on goldens
Original PR Author: dkwingsmt
Reviewed By: {chunhtai}
This change reverts the following previous change:
Relands #149568, which was reverted in https://github.com/flutter/flutter/pull/149998 due to unverified golden tests post-commit. (Honestly I don't know what happened but I guess resubmitting should resolve it.)
No code is changed.
Dart2Wasm doesn't officially support `dart:ffi` (only a small sketchy
subset needed in flutter web engine). We have seen user reporting issues
where existing packages don't work with dart2wasm due to using
`dart.library.ffi` in `bool.fromEnvironment` or in conditional imports
and it doing the wrong thing. So we're going to make `dart.library.ffi`
`false` in the compiler.
We therefore update the code to detect whether it runs under wasm via a
new `dart.tool.dart2wasm` environment variable.
This is a preparation for the change in dart2wasm which will start
making `const bool.fromEnvironment('dart.library.ffi')` return `false`
instead of `true`.
Notifies the engine when `PointerSignalEvents` have been ignored by the framework, through the `ui.PointerData.respond` method.
This allows the web to "preventDefault" (or not) on `wheel` events.
## Issues
* Fixes (partially): https://github.com/flutter/flutter/issues/139263
## Tests
* Added tests to ensure `respond` is called at the right time, with the right value.
## Demo
* https://dit-multiview-scroll.web.app
<details>
<summary>
## Previous versions
</summary>
1. Modified `PointerScrollEvent`, not shippable.
2. Modified when events were handled, instead of the opposite.
</details>
This PR addresses an issue with TextPainter's caret position calculation for text containing full-width spaces. Currently, the caret position is not accurately calculated for strings with full-width spaces. To resolve this, the following changes have been made:
Corrected the logic for caret position calculation when full-width spaces are present in the text.
Added and updated test cases to ensure accurate caret position calculation.
These changes ensure that the caret position for text with full-width spaces is computed correctly.
This issue was introduced by the commit [a0a854a](a0a854a78b).
Related Issue: [#149099](https://github.com/flutter/flutter/issues/149099)
- When `--web-renderer` is omitted, keep the value `null` until it later materializes to either `canvaskit` or `skwasm`.
- No more hardcoded defaults anywhere. We use `WebRendererMode.defaultForJs/defaultForWasm` instead.
- When in `--wasm` mode, the JS fallback is now `canvaskit` instead of `auto`.
- Add test for defaulting to `skwasm` when `--wasm` is enabled.
Fixes https://github.com/flutter/flutter/issues/149826
This reverts commit 32081aab69f82f88283cf43ce4cc2f9544c7c16c.
Reason for revert: Appears to be failing tests in tree
```
01:48 +2991 ~18: /Volumes/Work/s/w/ir/x/w/flutter/packages/flutter/test/cupertino/action_sheet_test.dart: Taps on a button can be slided to other buttons
âââ¡ EXCEPTION CAUGHT BY FLUTTER TEST FRAMEWORK âââââââââââââââââââââââââââââââââââââââââââââââââââââ
The following SkiaException was thrown while running async test code:
Skia Gold received an unapproved image in post-submit
testing. Golden file images in flutter/flutter are triaged
in pre-submit during code review for the given PR.
Visit https://flutter-gold.skia.org/ to view and approve
the image(s), or revert the associated change. For more
information, visit the wiki:
https://github.com/flutter/flutter/wiki/Writing-a-golden-file-test-for-package:flutter
Debug information for Gold --------------------------------
stdout: Given image with hash 601f421e3bb643f437cc12395de96152 for test
cupertino.cupertinoActionSheet.press-drag
Expectation for test: ce8ef79c146857d162663b1161fd6d5c (positive)
Expectation for test: 3bb57a8782f67836c6ad3ece7f00729a (positive)
Expectation for test: 3f8c592774caf3c760fbbd318a7dc5af (positive)
Expectation for test: 61863f38217aa3349c239eeb49b84930 (positive)
Expectation for test: 98af16e9b7eb3fb810b44c74bb18ffb9 (positive)
Untriaged or negative image:
https://flutter-gold.skia.org//detail?grouping=name%3Dcupertino.cupertinoActionSheet.press-drag%26source_type%3Dflutter&digest=601f421e3bb643f437cc12395de96152
stderr: Test: cupertino.cupertinoActionSheet.press-drag FAIL
result-state.json: No result file found.
```
This PR matches the various colors of `CupertinoActionSheet` more closely with the native one.
The following colors are changed.
* Sheet background color
* Pressed button color
* Cancel button color
* Pressed cancel button color
* Divider color
* Content text color
The resulting colors match with native one with deviation of at most 1 (in terms of 0~255 RGB).
The following are comparison (left to right: Native, Flutter after PR, Flutter current)
<img width="1295" alt="image" src="https://github.com/flutter/flutter/assets/1596656/3703a4a8-a856-42b1-9395-a6e14b1881ca">
<img width="1268" alt="image" src="https://github.com/flutter/flutter/assets/1596656/1eb9964e-41f1-414a-99ae-0a2e7da8d3fd">
_Note: The divider thickness is adjusted to `1/dpr` instead of 0.3 in both Flutter version to make them look more native, as will be proposed in https://github.com/flutter/flutter/pull/149636._
### Derivation
All the colors are derived through color picker and calculation. The algorithm is as followed:
* Assume all colors are translucent grey colors, i.e. having the same value `x` for R, G, and B, with an alpha `a`.
* Given the barrier color is `x_B1=0` when the background is black, and `x_B2=204` when the background is white.
* Pick the target color `x_t1` when the background is black, and `x_t2` when the background is white
* Solve the following equations for `x` and `a`
```
a * x + (1-a) * x_B1 = x_t1
a * x + (1-a) * x_B2 = x_t2
a = 1 - (x_t1 - x_t2) / (x_B1 - x_B2)
x = (x_t1 - (1-a) * x_B1) / a
```
These equations use a linear model for color composition, which might not be exact, but is close enough for an accuracy of (1/255).
The full table is as follows:
<img width="1091" alt="image" src="https://github.com/flutter/flutter/assets/1596656/0fb76291-c3cc-4bb5-aefa-03ac6ac9bf1f">
* The first two columns are colors picked from XCode.
* The 3~4 columns are the colors picked from the current Flutter. Notice the deviation, which is sometimes drastic.
* The 5~6 columns are the colors picked from Flutter after this PR. The deviation is at most 1.
* The last few columns are calculation.
* There are two rows whose calculation is based on adjusted numbers, since the original results are not accurate enough, possibly due to the linear composition.
During the calculation, I assumed these colors vary between light and dark modes, but it turns out that both modes use the same set of colors.
### Screenshots
This reverts commit 9d1de7b674866e3c8726aa5c949200eb3eb886ea.
Reverts due to log spam and crashing of the dependency version checker (which doesn't block the build but still isn't the desired outcome).
Work towards https://github.com/flutter/devtools/issues/7894
The Flutter DevTools team is working on a new Widget Inspector. As part of this work, we need to make adjusts to the widget inspector service API.
This PR simply re-factors the `widget_inspector_test` in preparation for this work, to make it easier for us to modify the tests / add new tests.
Although this PR is large (`widget_inspector_test` is over 5000 lines!!), it does not change any of the current test logic.
Instead it:
- Moves test cases that were prefixed with "WidgetInspectorService" into the pre-existing group named "WidgetInspectorService"
- Moves tests cases in that group which were skipped with `!WidgetInspectorService.instance.isWidgetCreationTracked() // [intended] Test requires --track-widget-creation flag` into a group called "Requires flag --track-widget-creation"
- Adds two helper functions, `pumpWidgetTreeWithABC` and `findElementABC` and uses them in all test cases that were duplicating the same widget set-up.
If the service is disposed when we make calls on it, we need to bubble up an exception that is understood by the callers.
This is another speculative fix for https://github.com/flutter/flutter/issues/149238.
We have fiddled with this a bunch, and there is definitively no way to reliably include this, so I am removing it.
Since CI does not cover all possible values, we can't consistently look up images for local testing. We thought removing it from the look up would work fine, and it did for most tests, but there were still some that could not find an image without it.
A brief history on the abi key
- added in https://github.com/flutter/flutter/pull/143621
- disabled in https://github.com/flutter/flutter/pull/148023
- added back in https://github.com/flutter/flutter/pull/148072
- we thought there was only an issue with alphabetizing keys
- removed from local image look up in https://github.com/flutter/flutter/pull/149696
I updated the docs page to also discuss what makes a good key and what does not based on what we learned here.
This PR implements the `CupertinoActionSheet` part of https://github.com/flutter/flutter/issues/19786.
This PR creates a new kind of gesture "sliding tap", which can be a simple tap but also allows the user to slide to other buttons during the tap, and select the button that the slide ends in.
The following video shows the behavior on a button list (left to right: Native iOS, after PR, before PR):
https://github.com/flutter/flutter/assets/1596656/1718630d-6890-4833-908b-762332a39568
Notice:
1. When the tap starts on a button or on the content section, the gesture can slide into a button to highlight it or activate it.
2. When the user performs a quick tap on a button, the button is immediately highlighted. (Before the PR, the highlight waits until the time out of a tap gesture, causing a quick tap to not highlight anything at all.)
The following video shows the behavior when the actions section scrolls (left to right: Native iOS, after PR)
https://github.com/flutter/flutter/assets/1596656/5eb70bc1-ec25-4376-9500-2aaa12f0034b
Notice:
1. Moving left or right doesn't cancel sliding tap, but moving vertically prioritizes the scrolling.
2. Moving before the drag starts is also recognized as a sliding tap.
Also, multiple pointers interact with the button list following an algorithm of "using earliest pointer". I can't record videos about it but I've added unit tests.
A sliver that is pinned to the start of its `CustomScrollView` and reacts to scrolling by resizing between the intrinsic sizes of its min and max extent prototypes.
The minimum and maximum sizes of this sliver are defined by `minExtentPrototype` and `maxExtentPrototype`, a pair of widgets that are laid out once. You can use `SizedBox` widgets to define the size limits.
This sliver is preferable to the general purpose `SliverPersistentHeader` for its relatively narrow use case because there's no need to create a `SliverPersistentHeaderDelegate` or to predict the header's minimum or maximum size.
The sample shows how this sliver's two extent prototype properties can be used to create a resizing header whose minimum and maximum sizes match small and large configurations of the same header widget.
https://github.com/flutter/flutter/assets/1377460/fa7ced98-9d92-4d13-b093-50392118c213
Related sliver utility PRs: https://github.com/flutter/flutter/pull/143538, https://github.com/flutter/flutter/pull/143196, https://github.com/flutter/flutter/pull/127340.
This change adds a new property in Semantics widget that would take an integer corresponding to the heading levels defined by the ARIA heading role. This is necessary in order to get proper accessibility and usability in a website for users who rely on screen readers and other assistive technologies.
Issue fixed by this PR:
fixes https://github.com/flutter/flutter/issues/97894
Engine part:
https://github.com/flutter/engine/pull/41435
Unpin `archive` version and run `flutter update-packages --force-upgrade` to show there are no additional dependencies pulled in (url_launcher was updated, but unrelated).
Fixes https://github.com/flutter/flutter/issues/149427
Fixes https://github.com/flutter/flutter/issues/149435
CI does not comprehensively cover all of the possible abi keys, so some folks can't test locally if their machine's abi does not match CI. This just removes it from the local testing look up. The right image will be summoned, and in CI we can still keep track of it.
fixes https://github.com/flutter/flutter/issues/142393
The issue is that if routerdelegate mutate its currentConfiguration outside of Router's workflow, the change will be propagate back to routeinformationprovider at the end of the frame.
However if another things trigger router's dependencies change within the same frame. The dependencies will trigger a reparse of the current route which would end up override the currentConfiguration in routerDelegate.
This change introduce a transaction system that each operation will be add to the end of the transaction future so everything will be execute inorder
In service of #146879. In summary, a bunch of `printTrace` calls were added to try to troubleshoot this flake, but the flake has stopped happening.
This PR more-or-less reverts https://github.com/flutter/flutter/pull/148596, since this was the only change that could have _theoretically_ (somehow maybe) stopped the flake. I'll consider reverting the rest of the `printTrace` calls if the flake does not reappear after this PR lands.
Looks like I did not need this flag since flutter_portal pinned flutter version to 3.10 in their presubmits.
I'll create a g3 fix for this since there're only a handful of scuba failures. Also a g3 test revealed a problem with calling `renderObject.markNeedsLayout` directly. It has to be deferred so the render tree is clean during the idle phase and the postFrameCallback phase.
This PR adds `AnimatedList.separated`. A widget like an AnimatedList with animated separators. `animated_list_separated.0.dart` extends `animated_list.0.dart` to work with `AnimatedList.separated`
Related issue: https://github.com/flutter/flutter/issues/48226
Reverts: flutter/flutter#142942
Initiated by: zanderso
Reason for reverting: Seems to have affected iOS platform view focus: https://ci.chromium.org/ui/p/flutter/builders/prod/Mac_ios%20native_platform_view_ui_tests_ios/10626/overview
Original PR Author: gspencergoog
Reviewed By: {yjbanov, goderbauer, chunhtai}
This change reverts the following previous change:
## Description
This causes the `Focus` widget to request focus on its focus node if the accessibility system (screen reader) focuses a widget via the `SemanticsAction.focus` action.
## Related Issues
- https://github.com/flutter/flutter/issues/83809
## Tests
- Added a test to make sure that focus is requested when `SemanticsAction.focus` is sent by the engine.
## Description
This causes the `Focus` widget to request focus on its focus node if the accessibility system (screen reader) focuses a widget via the `SemanticsAction.focus` action.
## Related Issues
- https://github.com/flutter/flutter/issues/83809
## Tests
- Added a test to make sure that focus is requested when `SemanticsAction.focus` is sent by the engine.
The application of the `dependency_version_checker` gradle plugin is wrapped in a try catch, which prevented blocking the build in https://github.com/flutter/flutter/pull/149204. This pr re-throws the errors we intended to throw.
The scroll notification events reported for a press-drag-release gesture within a scrollable on a touch screen device begin with a `ScrollStartNotification`, followed by a series of `ScrollUpdateNotifications`, and conclude with a `ScrollEndNotification`. This protocol can be used to defer work until an interactive scroll gesture ends. For example, you might defer updating a scrollable's contents via network requests until the scroll has ended, or you might want to automatically auto-scroll at that time.
In the example that follows the CustomScrollView automatically scrolls so that the last partially visible fixed-height item is completely visible when the scroll gesture ends. Many iOS applications do this kind of thing. It only makes sense to auto-scroll when the user isn't actively dragging the scrollable around.
It's easy enough to do this by reacting to a ScrollEndNotifcation by auto-scrolling to align the last fixed-height list item ([source code](https://gist.github.com/HansMuller/13e2a7adadc9afb3803ba7848b20c410)).
https://github.com/flutter/flutter/assets/1377460/a6e6fc77-6742-4f98-81ba-446536535f73
Dragging the scrollbar thumb in a desktop application is a similar user gesture. Currently it's not possible to defer work or auto-scroll (or whatever) while the scrollable is actively being dragged via the scrollbar thumb because each scrollbar thumb motion is mapped to a scroll start - scroll update - scroll end series of notifications. On a desktop platform, the same code behaves quite differently when the scrollbar thumb is dragged.
https://github.com/flutter/flutter/assets/1377460/2593d8a3-639c-407f-80c1-6e6f67fb8c5f
The stream of scroll-end events triggers auto-scrolling every time the thumb moves. From the user's perspective this feels like a losing struggle.
One can also detect the beginning and end of a touch-drag by listening to the value of a ScrollPosition's `isScrollingNotifier`. This approach suffers from a similar problem: during a scrollbar thumb-drag, the `isScrollingNotifier` value isn't updated at all.
This PR refactors the RawScrollbar implementation to effectively use a ScrollDragController to manage scrolls caused by dragging the scrollbar's thumb. Doing so means that dragging the thumb will produce the same notifications as dragging the scrollable on a touch device.
Now desktop applications can choose to respond to scrollbar thumb drags in the same that they respond to drag scrolling on a touch screen. With the changes included here, the desktop or web version of the app works as expected, whether you're listing to scroll notifications or the scroll position's `isScrollingNotifier`.
https://github.com/flutter/flutter/assets/1377460/67435c40-a866-4735-a19b-e3d68eac8139
This PR also makes the second [ScrollPosition API doc example](https://api.flutter.dev/flutter/widgets/ScrollPosition-class.html#cupertino.ScrollPosition.2) work as expected when used with the DartPad that's part of API doc page.
Desktop applications also see scroll start-update-end notifications due to the mouse wheel. There is no touch screen analog for the mouse wheel, so an application that wanted to enable this kind of auto-scrolling alignment would have to include a heuristic that dealt with the sequence of small scrolls triggered by the mouse wheel. Here's an example of that: [source code](https://gist.github.com/HansMuller/ce5c474a458f5f4bcc07b0d621843165). This version of the app does not auto-align in response to small changes, wether they're triggered by dragging the scrollbar thumb of the mouse wheel.
Related sliver utility PRs: https://github.com/flutter/flutter/pull/143538, https://github.com/flutter/flutter/pull/143196, https://github.com/flutter/flutter/pull/143325.
## Description
This adds the ability for `find.byTooltip` to use a `RegEx` to match the tooltip.
Also, adds some tests for `byTooltip`, since there weren't any.
## Tests
- added tests
This PR changes `CupertinoActionSheet`'s layout algorithm, so that the actions section always has the lower priority to take up vertical space with a fixed minimum height of 84.3 px.
Currently `CupertinoActionSheet` uses a very complicated rule the determine the sizes of various sections:
1. If there are <= 3 buttons and a cancel button, or 1 button without a cancel button, then the actions section should never scroll.
2. Otherwise, then the content section takes priority to take over spaces but must leave at least `actionsMinHeight` for the actions section.
This has been the case since `CupertinoActionSheet` was first introduced ([first PR](https://github.com/flutter/flutter/pull/19232)). Maybe it was the case before, but it's no longer reproducible on the latest SwiftUI.
The following images for comparison (left to right: Current Flutter, Flutter after this PR, SwiftUI). Pay attention to whether the actions section scrolls. (There are also some height/padding issues, which will be fixed in a future PR.)
Two buttons:
<img width="1006" alt="image" src="https://github.com/flutter/flutter/assets/1596656/27ca5df7-1140-4bfd-9a5f-3b5972632c92">
Three buttons:
<img width="1025" alt="image" src="https://github.com/flutter/flutter/assets/1596656/f2be6a5c-1713-4ffe-9705-27a668e5133d">
Four buttons:
<img width="1024" alt="image" src="https://github.com/flutter/flutter/assets/1596656/5b90d9f4-11ed-4c04-bdea-0b81b1d2bd3d">
In SwiftUI, the action section seems to always have a minimum height of ~84 pixels regardless of the number of buttons. Therefore this PR also fixed this behavior, and adjusted the related tests.
