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
Relands https://github.com/flutter/flutter/pull/149739 which was reverted due to https://github.com/flutter/flutter/issues/149851
---
fixes [`SegmentedButton` doesn't clip properly when one of the segments has `ColorFiltered`](https://github.com/flutter/flutter/issues/144990)
### Code sample
<details>
<summary>expand to view the code sample</summary>
```dart
import 'package:flutter/material.dart';
void main() => runApp(const MyApp());
class MyApp extends StatelessWidget {
const MyApp({super.key});
@override
Widget build(BuildContext context) {
return MaterialApp(
home: Scaffold(
body: Center(
child: SegmentedButton<int>(
segments: const <ButtonSegment<int>>[
ButtonSegment<int>(
value: 0,
label: ColorFiltered(
colorFilter:
ColorFilter.mode(Colors.amber, BlendMode.colorBurn),
child: Text('Option 1'),
),
),
ButtonSegment<int>(
value: 1,
label: Text('Option 2'),
),
],
onSelectionChanged: (Set<int> selected) {},
selected: const <int>{0},
),
),
),
);
}
}
```
</details>
### Before
### After
*Replace this paragraph with a description of what this PR is changing or adding, and why. Consider including before/after screenshots.*
*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].*
Adds `mouseCursor` property in `Radio` to `CupertinoRadio` and `Radio.adaptive`.
The `mouseCursor` property added is of type `MouseCursor` and not `WidgetStateProperty<MouseCursor>` to match `Radio`'s `mouseCursor`.
## Description
This PRs fixes `DropdownMenu` behaviors when disabled.
Before this PR the `DropdownMenu` value can be changed when `DropdownMenu.enabled` was false because the inner `IconButton` was not disabled so it can get focus (for instance using tab key).
After this PR, the inner `TextField` and the inner `IconButton` are disabled when `DropdownMenu.enabled` is false.
## Related Issue
Fixes https://github.com/flutter/flutter/issues/149598.
## Tests
Updates 1 test.
Adds 1 test.
The new service extension `getRootWidgetTree` can be used instead of the existing:
* `getRootWidgetSummaryTree` --> use`getRootWidgetTree` with parameters `isSummaryTree=true`
* `getRootWidgetSummaryTreeWithPreviews` --> use `getRootWidgetTree` with parameters `isSummaryTree=true` and `withPreviews=true`
This new service extension will enable Flutter DevTools to combine the widget summary tree with the widget details tree by calling `getRootWidgetTree` with `isSummary=false` and `withPreviews=true`.
Closes https://github.com/flutter/devtools/issues/7894
This sentence didn't make a lot of sense as written. It looks like
it was probably based on the doc of invokeMapMethod, and then
incompletely adapted. So, fix it.
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)
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 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
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
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 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.
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.
When I implemented https://github.com/flutter/flutter/pull/149334, there was a bug that if the actions section is overscrolled for too far (typically due to a fling), the overscroll background might be so long that it overflows the actions section. This PR fixes this bug.
