Reverts flutter/flutter#144001
Initiated by: Piinks
Reason for reverting: Failing goldens at the tip of tree
Original PR Author: QuncCccccc
Reviewed By: {HansMuller}
This change reverts the following previous change:
Original Description:
Reverts flutter/flutter#143973
This is a reland for #138521 with an updated g3fix(cl/605555997). Local test: cl/609608958.
The original PR was reverted because the new caret positioning callpath triggered a skparagraph assert. The assert has been removed. Relanding the PR with no changes applied.
This pull request fixes#143803 by taking advantage of Dart's null-aware operators.
And unlike `switch` expressions ([9 PRs](https://github.com/flutter/flutter/pull/143634) and counting), the Flutter codebase is already fantastic when it comes to null-aware coding. After refactoring the entire repo, all the changes involving `?.` and `??` can fit into a single pull request.
Adds a localized Close Button tooltip to the 'X' Button on a SnackBar, making it readable by screen readers.
Github Issue #143793
*If you had to change anything in the [flutter/tests] repo, include a link to the migration guide as per the [breaking change policy].*
fixes [`hourMinuteTextStyle` Material 3 default doesn't match the specs](https://github.com/flutter/flutter/issues/143748)
This updates `hourMinuteTextStyle` defaults to match Material 3 specs. `hourMinuteTextStyle` should use different font style for different entry modes based on the specs.
### Specs
### Before
```dart
return _textTheme.displayMedium!.copyWith(color: _hourMinuteTextColor.resolve(states));
```
### After
```dart
return entryMode == TimePickerEntryMode.dial
? _textTheme.displayLarge!.copyWith(color: _hourMinuteTextColor.resolve(states))
: _textTheme.displayMedium!.copyWith(color: _hourMinuteTextColor.resolve(states));
```
Reverts flutter/flutter#143281
Initiated by: LongCatIsLooong
Reason for reverting: https://github.com/flutter/flutter/issues/143797
Original PR Author: LongCatIsLooong
Reviewed By: {justinmc, jason-simmons}
This change reverts the following previous change:
Original Description:
The behavior largely remains the same, except:
1. The EOT cursor `(textLength, downstream)` for text ending in the opposite writing direction as the paragraph is now placed at the visual end of the last line.
For example, in a LTR paragraph, the EOT cursor for `aA` (lowercase for LTR and uppercase for RTL) is placed to the right of the line: `aA|` (it was `a|A` before).
This matches the behavior of most applications that do logical order arrow key navigation instead of visual order navigation.
And it makes the navigation order consistent for `aA\naA`:
```
|aA => aA| => aA| => aA => aA => aA
aA aA aA |aA aA| aA|
(1) (2) (3) (4) (5) (6)
```
This is indeed still pretty confusing as (2) and (3), as well as (5) and (6) are hard to distinguish (when the I beam has a large width they are actually visually distinguishable -- they use the same anchor but one gets painted to the left and the other to the right. I noticed that emacs does the same).
But logical order navigation will always be confusing in bidi text, in one way or another.
Interestingly there are 3 different behaviors I've observed in chrome:
- the chrome download dialog (which I think uses GTK text widgets but not sure which version) gives me 2 cursors when navigating bidi text, and
- its HTML fields only show one, and presumably they place the I beam at the **trailing edge** of the character (which makes more sense for backspacing I guess).
- On the other hand, its (new) omnibar seems to use visual order arrow navigation
Side note: we may need to update the "tap to place the caret here" logic to handle the case where the tap lands outside of the text and the text ends in the opposite writing direction.
2. Removed the logarithmic search. The same could be done using the characters package but when glyphInfo tells you about the baseline location in the future we probably don't need the `getBoxesForRange` call. This should fix https://github.com/flutter/flutter/issues/123424.
## Internal Tests
This is going to change the image output of some internal golden tests. I'm planning to merge https://github.com/flutter/flutter/pull/143281 before this to avoid updating the same golden files twice for invalid selections.
The behavior largely remains the same, except:
1. The EOT cursor `(textLength, downstream)` for text ending in the opposite writing direction as the paragraph is now placed at the visual end of the last line.
For example, in a LTR paragraph, the EOT cursor for `aA` (lowercase for LTR and uppercase for RTL) is placed to the right of the line: `aA|` (it was `a|A` before).
This matches the behavior of most applications that do logical order arrow key navigation instead of visual order navigation.
And it makes the navigation order consistent for `aA\naA`:
```
|aA => aA| => aA| => aA => aA => aA
aA aA aA |aA aA| aA|
(1) (2) (3) (4) (5) (6)
```
This is indeed still pretty confusing as (2) and (3), as well as (5) and (6) are hard to distinguish (when the I beam has a large width they are actually visually distinguishable -- they use the same anchor but one gets painted to the left and the other to the right. I noticed that emacs does the same).
But logical order navigation will always be confusing in bidi text, in one way or another.
Interestingly there are 3 different behaviors I've observed in chrome:
- the chrome download dialog (which I think uses GTK text widgets but not sure which version) gives me 2 cursors when navigating bidi text, and
- its HTML fields only show one, and presumably they place the I beam at the **trailing edge** of the character (which makes more sense for backspacing I guess).
- On the other hand, its (new) omnibar seems to use visual order arrow navigation
Side note: we may need to update the "tap to place the caret here" logic to handle the case where the tap lands outside of the text and the text ends in the opposite writing direction.
2. Removed the logarithmic search. The same could be done using the characters package but when glyphInfo tells you about the baseline location in the future we probably don't need the `getBoxesForRange` call. This should fix https://github.com/flutter/flutter/issues/123424.
## Internal Tests
This is going to change the image output of some internal golden tests. I'm planning to merge https://github.com/flutter/flutter/pull/143281 before this to avoid updating the same golden files twice for invalid selections.
## Description
This PR is the third step for the M3 test migration for `InputDecorator`.
Step 1: https://github.com/flutter/flutter/pull/142981
Step 2: https://github.com/flutter/flutter/pull/143369
This PR moves some tests out of the 'Material2' group (the ones that are ok on M3).
@justinmc The diff is almost unreadable, I moved the tests as carefully as possible and I checked that before and after the number of tests is exactly the same.
## Related Issue
Related to https://github.com/flutter/flutter/issues/139076
## Tests
Move some tests from 'Material2' group to main().
Fixes https://github.com/flutter/flutter/issues/79495
This is basically a reland of https://github.com/flutter/flutter/pull/79607.
Currently when the cursor is invalid, arrow key navigation / typing / backspacing doesn't work since the cursor position is unknown.
Showing the cursor when the selection is invalid gives the user the wrong information about the current insert point in the text.
This is going to break internal golden tests.
Reverts flutter/flutter#143334
Initiated by: hangyujin
Reason for reverting: broke g3 tests
Original PR Author: hangyujin
Reviewed By: {LongCatIsLooong}
This change reverts the following previous change:
Original Description:
Add a semantics flag to text field to fix https://github.com/flutter/flutter/issues/143337 (in IOS the disabled text field is not read `dimmed`)
internal: b/322345393
## Description
This PR is the second step for the M3 test migration for `InputDecorator` (step 1 was https://github.com/flutter/flutter/pull/142981).
This PR migrate the two first tests of the M2 section. Those were big tests. I splitted them in several testsn organized in groups, and I narrowed their scope when possible.
@justinmc I did not move yet the M2 tests to a separate file (I move them to a group) because it would mean we loss the line history which is useful during the migration. In the next step, I will focus on moving out some tests that are in the 'Material2' group (the ones that are ok with both M2 and M3).
## Related Issue
Related to https://github.com/flutter/flutter/issues/139076
## Tests
Adds several tests for M3.
fixes [The InputDecoration's suffix and prefix widget can be tapped even if it does not appear](https://github.com/flutter/flutter/issues/139916)
This PR also updates two existing tests to pass the tests for this PR. These tests are trying to tap prefix and suffix widgets when they're hidden. While the linked issue had visible prefix and suffix widgets https://github.com/flutter/flutter/issues/39376 for reproduction.
### Code sample
<details>
<summary>expand to view the code sample</summary>
```dart
import 'package:flutter/material.dart';
void main() {
runApp(MainApp());
}
class MainApp extends StatelessWidget {
final _messangerKey = GlobalKey<ScaffoldMessengerState>();
MainApp({super.key});
@override
Widget build(BuildContext context) {
return MaterialApp(
scaffoldMessengerKey: _messangerKey,
home: Scaffold(
body: Container(
alignment: Alignment.center,
padding: const EdgeInsets.all(16.0),
child: TextField(
decoration: InputDecoration(
labelText: 'Something',
prefix: GestureDetector(
onTap: () {
_messangerKey.currentState?.showSnackBar(
const SnackBar(content: Text('A tap has occurred')));
},
child: const Icon(Icons.search),
),
suffix: GestureDetector(
onTap: () {
_messangerKey.currentState?.showSnackBar(
const SnackBar(content: Text('A tap has occurred')));
},
child: const Icon(Icons.search),
),
),
),
),
),
);
}
}
```
</details>
### Before
### After
Fixes#142896
The original code below is to always place the selected item above(overlap) the popup button so that the selected item can always be visible: f8a77225f3/packages/flutter/lib/src/material/popup_menu.dart (L723-L732)
But when menu height is constrained and the menu itself is super long, the selected item still assumes there is enough space to push up all the items whose index is smaller than the selected index. As a result, every time when the menu is open, the calculation provides a different result to be the offset for the selected index, and then with a constrained height, the menu looks jumping all over the place based on the different selected index.
https://github.com/flutter/flutter/assets/36861262/ad761f95-0ff5-4311-a81d-dac56df879c5
Even though the original calculation is to make the selected item visible when open the menu, the menu doesn't auto scroll and only expands itself as much as possible to show the selected one. In this case, if the screen it too small to show the selected item, we still cannot see it. This can be fixed by using `Scrollable.ensureVisible()`(#143118).
So we remove the calculation in this PR and the menu will always show up based on the top left of the anchor(button).
https://github.com/flutter/flutter/assets/36861262/03272f26-9440-4ac4-a701-9a0b41776ff9
Adding `SingleChildScrollView` to `NavigationRail` may cause exception if the nav rail has some expanded widgets inside, like the issue: https://github.com/flutter/flutter/issues/143061. This PR is just to add a unit test to avoid causing this breaking again.
Reverts flutter/flutter#138545
Initiated by: zanderso
Reason for reverting: Failing in post-submit: https://ci.chromium.org/ui/p/flutter/builders/prod/Linux%20web_long_running_tests_5_5/14975/overview
```
══╡ EXCEPTION CAUGHT BY FLUTTER TEST FRAMEWORK ╞═════════════════
The following FormatException was thrown running a test:
Invalid Shader Data
When the exception was thrown, this was the stack:
dart-sdk/lib/_internal/js_dev_runtime/private/ddc_runtime/errors.da
Original PR Author: bleroux
Reviewed By: {Piinks}
This change reverts the following previous change:
Original Description:
## Description
This PR activates the M3 `InkSparkle` splash animation on Android + CanvasKit.
Before it `InkSparkle` was only activated on native Android.
## Related Issue
Fixes https://github.com/flutter/flutter/issues/138487
## Tests
Updates several existing tests.
## Description
This PR activates the M3 `InkSparkle` splash animation on Android + CanvasKit.
Before it `InkSparkle` was only activated on native Android.
## Related Issue
Fixes https://github.com/flutter/flutter/issues/138487
## Tests
Updates several existing tests.
Fixes#128696 (Motion checkbox)
This PR updates the Material 3 tab indicator animation, so that it stretches, as it can be seen in the showcase videos in the specification https://m3.material.io/components/tabs/accessibility#13ed756b-fb35-4bb3-ac8c-1157e49031d8
One thing to note is that the Material 3 videos have a tab transition duration of 700 ms, whereas currently in Flutter the duration is 300 ms. I recorded 4 comparison videos to see the difference better (current animation vs stretch animation and 300 ms vs 700 ms)
@Piinks You mentioned the other day that the default tab size could be updated in the future to better reflect the new size in M3. Maybe the `kTabScrollDuration` constant is another one that could end up being updated, as 300 ms for this animation feels too fast.
Here are the comparison videos (Material 3 spec showcase on the left and Flutter on the right)
## Original animation - 300 ms
https://github.com/flutter/flutter/assets/22084723/d5b594fd-52ea-4328-b8e2-ddb597c81f69
## New animation - 300 ms
https://github.com/flutter/flutter/assets/22084723/c822f7ab-3fc4-4403-a53b-872d047f6227
---
## Original animation - 700 ms
https://github.com/flutter/flutter/assets/22084723/fe39a32d-3d10-4c0d-98df-bd5e1c9336d0
## New animation - 700 ms
https://github.com/flutter/flutter/assets/22084723/8d4b0628-6312-40c2-bd99-b4bcb8e23ba9
---
## Code sample
```dart
void main() => runApp(const MyApp());
class MyApp extends StatelessWidget {
const MyApp({super.key});
@override
Widget build(BuildContext context) {
return const MaterialApp(
debugShowCheckedModeBanner: false,
home: TabExample(),
);
}
}
class TabExample extends StatelessWidget {
const TabExample({super.key});
@override
Widget build(BuildContext context) {
return DefaultTabController(
initialIndex: 1,
length: 3,
child: Scaffold(
appBar: AppBar(
title: const Text('My saved media'),
bottom: const TabBar(
tabs: <Widget>[
Tab(
icon: Icon(Icons.videocam_outlined),
text: "Video",
),
Tab(
icon: Icon(Icons.photo_outlined),
text: "Photos",
),
Tab(
icon: Icon(Icons.audiotrack),
text: "Audio",
),
],
),
),
body: const TabBarView(
children: <Widget>[
Center(
child: Text("Tab 1"),
),
Center(
child: Text("Tab 2"),
),
Center(
child: Text("Tab 3"),
),
],
),
),
);
}
}
```
*If you had to change anything in the [flutter/tests] repo, include a link to the migration guide as per the [breaking change policy].*
This change affects Android and iOS devices using the TextField's context menu. After this change the context menu will fade out when scrolling the text and fade in when the scroll ends.
If the scroll ends and the selection is outside of the view, then the toolbar will be scheduled to show in a future scroll end. This toolbar scheduling can be invalidated if the `TextEditingValue` changed anytime between the scheduling and when the toolbar is ready to be shown.
This change also fixes a regression where the TextField context menu would not fade when the selection handles where not visible.
When using the native browser context menu this behavior is not controlled by Flutter.
https://github.com/flutter/flutter/assets/948037/3f46bcbb-ba6f-456c-8473-e42919b9d572Fixes#52425Fixes#105804Fixes#52426
Reland https://github.com/flutter/flutter/pull/141818 with a fix for a special case: If only `background` is specified for `TextButton.styleFrom` or `OutlinedButton.styleFrom` it applies the button's disabled state, i.e. as if the same value had been specified for disabledBackgroundColor.
The change relative to #141818 is the indicated line below:
```dart
final MaterialStateProperty<Color?>? backgroundColorProp = switch ((backgroundColor, disabledBackgroundColor)) {
(null, null) => null,
(_, null) => MaterialStatePropertyAll<Color?>(backgroundColor), // ADDED THIS LINE
(_, _) => _TextButtonDefaultColor(backgroundColor, disabledBackgroundColor),
};
```
This backwards incompatibility cropped up in an internal test, see internal Google issue b/323399158.
