This PR is to update the token version to v6.1.
* This version fixes https://github.com/flutter/flutter/issues/153271
* Change the chip default border color from `ColorScheme.outline` to `ColorScheme.outlineVariant`. The Chips' border color is softened to improve visual hierarchy between chips and buttons
This PR adds a new constructor to the RefreshIndicator's class, which is `noSpinner`.
The purpose of this new constructor is to create a RefreshIndicator that doesn't show a spinner when the user arms it by pulling.
The work is based on a partial that is here: https://github.com/flutter/flutter/pull/133507
I addressed the following issues reported in the PR above:
- in the example for `noSpinner`, arming the RefreshIndicator now shows a CircularProgressIndicator, instead of just printing text to the console;
- added a test for the new example;
- added a doc comment on the new constructor;
Fixes https://github.com/flutter/flutter/issues/132775
This PR is aimed at (1) reducing the private API surface of _MenuAnchorState to make migration into RawMenuAnchor simpler, and (2) fixing focus-related bugs.
Directional focus handling was moved from MenuAnchor (_MenuDirectionalFocusAction, _MenuNextFocusAction, and _MenuPreviousFocusAction) into SubmenuButton (_SubmenuDirectionalFocusAction). MenuAnchor now behaves similarly to a flat FocusScope, which makes it easier to customize. A future PR will ideally expose or remove the remaining internals (_lastItemFocusNode, _firstItemFocusNode, _isRoot, etc). All previous framework tests are passing, and additional tests were added for fixes (MenuAnchor tab traversal, reopened menus not being focusable), and to test MenuAnchor focus behavior separately from MenuBar.
However, [one example test](https://github.com/flutter/flutter/pull/150950/files#diff-a33fa01b59d280784e7c8ed6b704bd005cde95b7d3b649dc82fd58530061a09d) had to be changed. I'm not sure why the previous example test was working to begin with, as submenu buttons are supposed to open on focus, but this behavior was not observed in the original test.
Fixes https://github.com/flutter/flutter/issues/144381, https://github.com/flutter/flutter/issues/150334.
One added feature is the ability to move between top-level horizontal submenus if a horizontal movement is made on a vertical menu item that has no children in the movement direction. This behavior was observed on Google Docs, MacOS, and various other menu systems I encountered.
https://github.com/flutter/flutter/assets/59215665/04a42b8a-cc9e-4a50-9d0c-6f2d784cfc78
Contributes to https://github.com/flutter/flutter/issues/130459
It adds a test for
- `examples/api/lib/material/scaffold/scaffold_messenger_state.show_snack_bar.0.dart`
- `examples/api/lib/material/scaffold/scaffold_messenger_state.show_material_banner.0.dart`
Contributes to https://github.com/flutter/flutter/issues/130459
It adds a test for
- `examples/api/lib/material/search_anchor/search_anchor.1.dart`
- `examples/api/lib/material/search_anchor/search_anchor.2.dart`
Contributes to https://github.com/flutter/flutter/issues/130459
It adds a test for
- `examples/api/lib/material/scaffold/scaffold_messenger.0.dart`
- `examples/api/lib/material/scaffold/scaffold_messenger.of.0.dart`
- `examples/api/lib/material/scaffold/scaffold_messenger.of.1.dart`
Reverts: flutter/flutter#150481
Initiated by: cbracken
Reason for reverting: Surprisingly, the following test seems to be consistently failing on Windows after the addition of this test:
```
flutter/packages/flutter/test/widgets/sliver_tree_test.dart: .toggleNodeWith, onNodeToggle
```
Original PR Author: ValentinVignal
Reviewed By: {TahaTesser, bleroux}
This change reverts the following previous change:
Contributes to https://github.com/flutter/flutter/issues/130459
It adds a test for
- `examples/api/lib/material/text_form_field/text_form_field.1.dart`
Add tests for `InputDecoration` API example as part of #130459. Updates examples that use the deprecated MaterialState to use WidgetState. Tests files: `input_decoration.0.dart`, `input_decoration.1.dart`, `input_decoration.2.dart`, `input_decoration.3.dart`, `input_decoration.widget_state.0.dart`, `input_decoration.widget_state.1.dart`, `input_decoration.prefix_icon_constraints.0.dart`, `input_decoration.suffix_icon_constraints.0.dart`, and `input_decoration.label.0.dart`
Introducing the `forceErrorText` property to both `FormField` and `TextFormField`. With this addition, we gain the capability to trigger an error state and provide an error message without invoking the `validator` method.
While the idea of making the `Validator` method work asynchronously may be appealing, it could introduce significant complexity to our current form field implementation. Additionally, this approach might not be suitable for all developers, as discussed by @justinmc in this [comment](https://github.com/flutter/flutter/issues/56414#issuecomment-624960263).
This PR try to address this issue by adding `forceErrorText` property allowing us to force the error to the `FormField` or `TextFormField` at our own base making it possible to preform some async operations without the need for any hacks while keep the ability to check for errors if we call `formKey.currentState!.validate()`.
Here is an example:
<details> <summary>Code Example</summary>
```dart
import 'package:flutter/material.dart';
void main() {
runApp(
const MaterialApp(home: MyHomePage()),
);
}
class MyHomePage extends StatefulWidget {
const MyHomePage({
super.key,
});
@override
State<MyHomePage> createState() => _MyHomePageState();
}
class _MyHomePageState extends State<MyHomePage> {
final key = GlobalKey<FormState>();
String? forcedErrorText;
Future<void> handleValidation() async {
// simulate some async work..
await Future.delayed(const Duration(seconds: 3));
setState(() {
forcedErrorText = 'this username is not available.';
});
// wait for build to run and then check.
//
// this is not required though, as the error would already be showing.
WidgetsBinding.instance.addPostFrameCallback((_) {
print(key.currentState!.validate());
});
}
@override
Widget build(BuildContext context) {
print('build');
return Scaffold(
floatingActionButton: FloatingActionButton(onPressed: handleValidation),
body: Form(
key: key,
child: Center(
child: Column(
mainAxisAlignment: MainAxisAlignment.center,
children: [
Padding(
padding: const EdgeInsets.symmetric(horizontal: 30),
child: TextFormField(
forceErrorText: forcedErrorText,
),
),
],
),
),
),
);
}
}
```
</details>
Related to #9688 & #56414.
Happy to hear your thoughts on this.
The widget under test already contains a MaterialApp, so there's no need to wrap it again with one in the test. In fact, the additional MaterialApp could hide problems in the widget under test.
## Description
This fixes the `ColorScheme` example to actually work. The test had wrapped the app in an additional `MaterialApp`, which allowed the tests to work, but the real problem was using a `context` that was outside the `MaterialApp` to open the bottom sheet, which caused an exception when you actually try to run it interactively.
This fixes the example and the test.
## Tests
- Fixed the test to not artificially add a second `MaterialApp`.
Contributes to https://github.com/flutter/flutter/issues/130459
It adds a test for
- `examples/api/lib/material/scaffold/scaffold.drawer.0.dart`
- `examples/api/lib/material/scaffold/scaffold.end_drawer.0.dart`
