## Add `bySemanticsIdentifier` finder for finding by identifier
### Description
This pull request introduces a new finder, `CommonFinders.bySemanticsIdentifier`, to the Flutter testing framework. This finder allows developers to locate `Semantics` widgets based on their `identifier` property, enhancing the precision and flexibility of widget tests.
### Motivation
Establish a consistent and reliable method for locating elements in integration and end-to-end (e2e) tests. Unlike `label` or `key`, which may carry functional significance within the application, the `identifier` is purely declarative and does not impact functionality. Utilizing the `identifier` for finding semantics widgets ensures that tests can target specific elements without interfering with the app's behavior, thereby enhancing test reliability, maintainability, and reusability across testing frameworks.
### Changes
- **semantics.dart**
- Updated documentation to mention that `identifier` can be matched using `CommonFinders.bySemanticsIdentifier`.
- **finders.dart**
- Added the `bySemanticsIdentifier` method to `CommonFinders`.
- Supports both exact string matches and regular expression patterns.
- Includes error handling to ensure semantics are enabled during tests.
- **finders_test.dart**
- Added tests to verify that `bySemanticsIdentifier` correctly finds widgets by exact identifier and regex patterns.
- Ensures that the finder behaves as expected when semantics are not enabled.
### Usage
Developers can use the new finder in their tests as follows:
```dart
// Exact match
expect(find.bySemanticsIdentifier('Back'), findsOneWidget);
// Regular expression match
expect(find.bySemanticsIdentifier(RegExp(r'^item-')), findsNWidgets(2));
```
This pull request aims to improve code readability, based on feedback gathered in a recent design doc.
<br>
There are two factors that hugely impact how easy it is to understand a piece of code: **verbosity** and **complexity**.
Reducing **verbosity** is important, because boilerplate makes a project more difficult to navigate. It also has a tendency to make one's eyes gloss over, and subtle typos/bugs become more likely to slip through.
Reducing **complexity** makes the code more accessible to more people. This is especially important for open-source projects like Flutter, where the code is read by those who make contributions, as well as others who read through source code as they debug their own projects.
<hr>
<br>
The following examples show how pattern-matching might affect these two factors:
<details> <summary><h3>Example 1 (GOOD)</h3> [click to expand]</summary>
```dart
if (ancestor case InheritedElement(:final InheritedTheme widget)) {
themes.add(widget);
}
```
Without using patterns, this might expand to
```dart
if (ancestor is InheritedElement) {
final InheritedWidget widget = ancestor.widget;
if (widget is InheritedTheme) {
themes.add(widget);
}
}
```
Had `ancestor` been a non-local variable, it would need to be "converted" as well:
```dart
final Element ancestor = this.ancestor;
if (ancestor is InheritedElement) {
final InheritedWidget inheritedWidget = ancestor.widget;
if (widget is InheritedTheme) {
themes.add(theme);
}
}
```
</details>
<details> <summary><h3>Example 2 (BAD) </h3> [click to expand]</summary>
```dart
if (widget case PreferredSizeWidget(preferredSize: Size(:final double height))) {
return height;
}
```
Assuming `widget` is a non-local variable, this would expand to:
```dart
final Widget widget = this.widget;
if (widget is PreferredSizeWidget) {
return widget.preferredSize.height;
}
```
<br>
</details>
In both of the examples above, an `if-case` statement simultaneously verifies that an object meets the specified criteria and performs a variable assignment accordingly.
But there are some differences: Example 2 uses a more deeply-nested pattern than Example 1 but makes fewer useful checks.
**Example 1:**
- checks that `ancestor` is an `InheritedElement`
- checks that the inherited element's `widget` is an `InheritedTheme`
**Example 2:**
- checks that `widget` is a `PreferredSizeWidget`
(every `PreferredSizeWidget` has a `size` field, and every `Size` has a `height` field)
<br>
<hr>
I feel hesitant to try presenting a set of cut-and-dry rules as to which scenarios should/shouldn't use pattern-matching, since there are an abundance of different types of patterns, and an abundance of different places where they might be used.
But hopefully the conversations we've had recently will help us converge toward a common intuition of how pattern-matching can best be utilized for improved readability.
<br><br>
- resolves https://github.com/flutter/flutter/issues/152313
- Design Doc: [flutter.dev/go/dart-patterns](https://flutter.dev/go/dart-patterns)
Recently the microbenchmarks were flakey, but from an older bug. Turns out, `LiveTestWidgetsFlutterBindingFramePolicy` is defaulted to `fadePointers` with this fun note:
> This can result in additional frames being pumped beyond those that
the test itself requests, which can cause differences in behavior
Both `text_intrinsic_bench` and `build_bench` use a similar pattern:
* Load stocks app
* Open the menu
* Switch to `benchmark` frame policy
What happens, rarely, is that
`LiveTestWidgetsFlutterBinding.pumpBenchmark()` will call (async) `handleBeginFrame` and `handleDrawFrame`. `handleDrawFrame` juggles a tri-state boolean (null, false, true). This boolean is only reset to `null` when handleDrawFrame is called back to back, say, from an extra frame that was scheduled.
1. Switch tri-state boolean to an enum, its easier to read
2. remove asserts that compile away in benchmarks (`--profile`)
3. use `Error.throwWithStackTrace` to keep stack traces.
I've been running this test on device lab hardware for hundreds of runs and have not hit a failure yet.
Fixes#150542Fixes#150543 - throw stack!
This migrates the last failing test for https://github.com/flutter/engine/pull/54981. In order to effectively resolve that test I had to make `equalsIgnoringHashCodes` more usable by printing out the line that differs instead of just a huge blob of "expected" vs "actual.
## example
Here's the output after the change.
### test
```
test('equalsIgnoringHashCodes - wrong line', () {
expect(
'1\n2\n3\n4\n5\n6\n7\n8\n9\n10',
equalsIgnoringHashCodes('1\n2\n3\n4\n5\n6\na\n8\n9\n10'),
);
});
```
### output
```
Expected: normalized value matches
'1\n'
'2\n'
'3\n'
'4\n'
'5\n'
'6\n'
'a\n'
'8\n'
'9\n'
'10'
Actual: '1\n'
'2\n'
'3\n'
'4\n'
'5\n'
'6\n'
'7\n'
'8\n'
'9\n'
'10'
Which: Lines 7 differed, expected:
'a'
but got
'7'
```
## Description
This adds `find.backButton()` in the Common Finders to allow finding different types of standard UI elements. It works by attaching a key made from an enum value in a new enum called `StandardComponentType` to all of the standard widgets that perform the associated function.
I also substituted the finder in several places where it is useful in tests.
This allows writing tests that want to find the "back" button without having to know exactly which icon the back button uses under what circumstances. To do it correctly is actually quite complicated, since there are several adaptations that occur (based on platform, and whether it is web or not).
## Tests
- Added tests.
## Description
This adds a call to the `PlatformDispatcher` whenever the focus changes, so that the engine can decide what to do about view focus. This lets widgets use autofocus, and when they are focused their view will also receive focus.
## Related Issues
- Fixes https://github.com/flutter/flutter/issues/151251
## Tests
- Added a test and some methods to the `TestPlatformDispatcher` to allow introspection of the values sent.
## Description
This re-enables the `SemanticsAction.focus` matchers so that they actually do something now instead of ignoring the action.
This was so that we could land the focus action changes without causing breakages in customer tests, and now that customer tests have been updated, we can land this PR turning it on again.
## Related Issues
- Fixes https://github.com/flutter/flutter/issues/149842
## Related PRs
- https://github.com/flutter/flutter/pull/149840
## Tests
- Updates semantics tests to actually look for the focus action.
There is a... restriction in dartdoc, such that a library which is
`@docImport`ed in one library, must be otherwise regularly imported in
some other library. Without this case, dartdoc gets a bit lost about
where the doc-imported library is.
Combine this restriction with analyzer's restriction that it doesn't
super duper handle configuration imports. Since `_goldens_io.dart` is
the "primary" import in all other files, and `_goldens_web.dart` is the
"configured" import, we must only doc-import `_goldens_io.dart`.
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>
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.
## 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 change fixes an issue where SelectionArea would clear its selection when the application window lost focus by first checking if the application is running. This is needed because `FocusManager` is aware of the application lifecycle as of https://github.com/flutter/flutter/pull/142930 , and triggers a focus lost if the application is not active.
Also fixes an issue where the `FocusManager` was not being reset on tests at the right time, causing it always to build with `TargetPlatform.android` as its context.
## Description
This factors out a separate `RawView` that doesn't add a `MediaQuery` or a `FocusScope`. This PR also adds a new method `WidgetsBindingObserver.didChangeViewFocus` which allows the observer to know when the `FlutterView` that has focus has changed.
It also makes the `View` widget a stateful widget that contains a `FocusScope` and ` FocusTraversalGroup` so that it can respond to changes in the focus of the view.
I've also added a new function to `FocusScopeNode` that will allow the scope node itself to be focused, without looking for descendants that could take the focus. This lets the focus be "parked" at the `FocusManager.instance.rootScope` so that nothing else appears to have focus.
## Tests
- Added tests for the new functionality.
This PR is step 12 in the journey to solve issue #136139 and make the
entire Flutter repo more readable.
Most of it involves implementing switch expressions, and there's also a
few other random things that I wanted to clean up a bit.
Reverts: flutter/flutter#148238
Initiated by: zanderso
Reason for reverting: Failures in post submit https://logs.chromium.org/logs/flutter/buildbucket/cr-buildbucket/8748025189669617649/+/u/run_test.dart_for_web_canvaskit_tests_shard_and_subshard_3/stdout
Original PR Author: justinmc
Reviewed By: {hellohuanlin}
This change reverts the following previous change:
Reland of https://github.com/flutter/flutter/pull/143002, which was reverted in https://github.com/flutter/flutter/pull/148237 due to unresolved docs references. Not sure why those weren't caught in presubmit.
```
dartdoc:stdout: Generating docs for package flutter...
dartdoc:stderr: error: unresolved doc reference [TextInput.showSystemContextMenu]
dartdoc:stderr: from widgets.MediaQueryData.supportsShowingSystemContextMenu: (file:///b/s/w/ir/x/w/flutter/packages/flutter/lib/src/widgets/media_query.dart:579:14)
dartdoc:stderr: in documentation inherited from widgets.MediaQueryData.supportsShowingSystemContextMenu: (file:///b/s/w/ir/x/w/flutter/packages/flutter/lib/src/widgets/media_query.dart:579:14)
dartdoc:stderr: error: unresolved doc reference [showSystemContextMenu]
dartdoc:stderr: from services.SystemContextMenuController.hide: (file:///b/s/w/ir/x/w/flutter/packages/flutter/lib/src/services/text_input.dart:2554:16)
dartdoc:stderr: error: unresolved doc reference [hideSystemContextMenu]
dartdoc:stderr: from services.SystemContextMenuController.show: (file:///b/s/w/ir/x/w/flutter/packages/flutter/lib/src/services/text_input.dart:2509:16)
```
It's now possible to use the native-rendered text selection context menu on iOS. This sacrifices customizability in exchange for avoiding showing a notification when the user presses "Paste". It's off by default, but to enable, see the example system_context_menu.0.dart.
Reverts: flutter/flutter#143002
Initiated by: cbracken
Reason for reverting: unresolved docs links. See failure here: https://ci.chromium.org/ui/p/flutter/builders/prod/Linux%20docs_test/16540/overview
```
dartdoc:stdout: Generating docs for package flutter...
dartdoc:stderr: error: unresolved doc reference [TextInput.showSystemContextMenu]
dartdoc:stderr: from widgets.MediaQueryData.supportsShowingSystemContextMenu: (file:///b/s/w/ir/x/w/flutter/packages/flutt
Original PR Author: justinmc
Reviewed By: {Renzo-Olivares, hellohuanlin}
This change reverts the following previous change:
In order to work around the fact that iOS 15 shows a notification on pressing Flutter's paste button (https://github.com/flutter/flutter/issues/103163), this PR allows showing the iOS system context menu in text fields.
<img width="385" alt="Screenshot 2024-02-06 at 11 52 25 AM" src="https://github.com/flutter/flutter/assets/389558/d82e18ee-b8a3-4082-9225-cf47fa7f3674">
It is currently opt-in, which a user would typically do like this (also in example system_context_menu.0.dart):
```dart
contextMenuBuilder: (BuildContext context, EditableTextState editableTextState) {
// If supported, show the system context menu.
if (SystemContextMenu.isSupported(context)) {
return SystemContextMenu.editableText(
editableTextState: editableTextState,
);
}
// Otherwise, show the flutter-rendered context menu for the current
// platform.
return AdaptiveTextSelectionToolbar.editableText(
editableTextState: editableTextState,
);
},
```
Requires engine PR https://github.com/flutter/engine/pull/50095.
## API changes
### SystemContextMenu
A widget that shows the system context menu when built, and removes it when disposed. The main high-level way that most users would use this PR. Only works on later versions of iOS.
### SystemContextMenuController
Used under the hood to hide and show a system context menu. There can only be one visible at a time.
### MediaQuery.supportsShowingSystemContextMenu
Sent by the iOS embedder to tell the framework whether or not the platform supports showing the system context menu. That way the framework, or Flutter developers, can decide to show a different menu.
### `flutter/platform ContextMenu.showSystemContextMenu`
Sent by the framework to show the menu at a given `targetRect`, which is the current selection rect.
### `flutter/platform ContextMenu.hideSystemContextMenu`
Sent by the framework to hide the menu. Typically not needed, because the platform will hide the menu when the user taps outside of it and after the user presses a button, but it handles edge cases where the user programmatically rebuilds the context menu, for example.
### `flutter/platform System.onDismissSystemContextMenu`
Sent by the iOS embedder to indicate that the system context menu has been hidden by the system, such as when the user taps outside of the menu. This is useful when there are multiple instances of SystemContextMenu, such as with multiple text fields.
It's now possible to use the native-rendered text selection context menu on iOS. This sacrifices customizability in exchange for avoiding showing a notification when the user presses "Paste". It's off by default, but to enable, see the example system_context_menu.0.dart.
* Adds support for `flutter test --wasm`.
* The test compilation flow is a bit different now, so that it supports compilers other than DDC. Specifically, when we run a set of unit tests, we generate a "switchboard" main function that imports each unit test and runs the main function for a specific one based off of a value set by the JS bootstrapping code. This way, there is one compile step and the same compile output is invoked for each unit test file.
* Also, removes all references to `dart:html` from flutter/flutter.
* Adds CI steps for running the framework unit tests with dart2wasm+skwasm
* These steps are marked as `bringup: true`, so we don't know what kind of failures they will result in. Any failures they have will not block the tree at all yet while we're still in `bringup: true`. Once this PR is merged, I plan on looking at any failures and either fixing them or disabling them so we can get these CI steps running on presubmit.
This fixes https://github.com/flutter/flutter/issues/126692
This pull request is part of the effort to solve issue #144903.
In the past, my efforts to reduce line length involved refactoring away from switch statements, but unlike [yesterday's PR](https://github.com/flutter/flutter/pull/144905), this one is full of switch statements that make things more concise!
Reverts: flutter/flutter#144706
Initiated by: gspencergoog
Reason for reverting: This has broken the tree because some tests are still failing post completion. This particular one looks like it might have to do with a gold image not existing.
Original PR Author: goderbauer
Reviewed By: {Piinks}
This change reverts the following previous change:
A test was failing silently because of this (see https://github.com/flutter/flutter/issues/144353 and fixed in https://github.com/flutter/flutter/pull/144709). The failure went undetected for months. Ideally, this should have been a regular non-silent failure. This change makes that so. `package:test` can properly handle reported exceptions outside of test cases. With this change, the test fails as follows:
```
00:03 +82: Smoke test material/color_scheme/dynamic_content_color.0.dart
══╡ EXCEPTION CAUGHT BY FLUTTER TEST FRAMEWORK ╞════════════════════════════════════════════════════
The following assertion was thrown running a test (but after the test had completed):
setState() called after dispose(): _DynamicColorExampleState#1cd37(lifecycle state: defunct, not
mounted)
This error happens if you call setState() on a State object for a widget that no longer appears in
the widget tree (e.g., whose parent widget no longer includes the widget in its build). This error
can occur when code calls setState() from a timer or an animation callback.
The preferred solution is to cancel the timer or stop listening to the animation in the dispose()
callback. Another solution is to check the "mounted" property of this object before calling
setState() to ensure the object is still in the tree.
This error might indicate a memory leak if setState() is being called because another object is
retaining a reference to this State object after it has been removed from the tree. To avoid memory
leaks, consider breaking the reference to this object during dispose().
When the exception was thrown, this was the stack:
#0 State.setState.<anonymous closure> (package:flutter/src/widgets/framework.dart:1167:9)
#1 State.setState (package:flutter/src/widgets/framework.dart:1202:6)
#2 _DynamicColorExampleState._updateImage (package:flutter_api_samples/material/color_scheme/dynamic_content_color.0.dart:191:5)
<asynchronous suspension>
════════════════════════════════════════════════════════════════════════════════════════════════════
00:03 +81 -1: Smoke test material/context_menu/context_menu_controller.0.dart
00:03 +81 -1: Smoke test material/color_scheme/dynamic_content_color.0.dart [E]
Test failed. See exception logs above.
The test description was: Smoke test material/color_scheme/dynamic_content_color.0.dart
This test failed after it had already completed.
Make sure to use a matching library which informs the test runner
of pending async work.
```
A test was failing silently because of this (see
https://github.com/flutter/flutter/issues/144353 and fixed in
https://github.com/flutter/flutter/pull/144709). The failure went
undetected for months. Ideally, this should have been a regular
non-silent failure. This change makes that so. `package:test` can
properly handle reported exceptions outside of test cases. With this
change, the test fails as follows:
```
00:03 +82: Smoke test material/color_scheme/dynamic_content_color.0.dart
══╡ EXCEPTION CAUGHT BY FLUTTER TEST FRAMEWORK ╞════════════════════════════════════════════════════
The following assertion was thrown running a test (but after the test had completed):
setState() called after dispose(): _DynamicColorExampleState#1cd37(lifecycle state: defunct, not
mounted)
This error happens if you call setState() on a State object for a widget that no longer appears in
the widget tree (e.g., whose parent widget no longer includes the widget in its build). This error
can occur when code calls setState() from a timer or an animation callback.
The preferred solution is to cancel the timer or stop listening to the animation in the dispose()
callback. Another solution is to check the "mounted" property of this object before calling
setState() to ensure the object is still in the tree.
This error might indicate a memory leak if setState() is being called because another object is
retaining a reference to this State object after it has been removed from the tree. To avoid memory
leaks, consider breaking the reference to this object during dispose().
When the exception was thrown, this was the stack:
#0 State.setState.<anonymous closure> (package:flutter/src/widgets/framework.dart:1167:9)
#1 State.setState (package:flutter/src/widgets/framework.dart:1202:6)
#2 _DynamicColorExampleState._updateImage (package:flutter_api_samples/material/color_scheme/dynamic_content_color.0.dart:191:5)
<asynchronous suspension>
════════════════════════════════════════════════════════════════════════════════════════════════════
00:03 +81 -1: Smoke test material/context_menu/context_menu_controller.0.dart
00:03 +81 -1: Smoke test material/color_scheme/dynamic_content_color.0.dart [E]
Test failed. See exception logs above.
The test description was: Smoke test material/color_scheme/dynamic_content_color.0.dart
This test failed after it had already completed.
Make sure to use a matching library which informs the test runner
of pending async work.
```
## Description
This PRs changes the default value for the `platform` parameter used to simulate key events.
With this PR, the default value is "web" on web, otherwise it is the operating system name retrieved from `defaultTargetPlatform`.
Previously, for methods in `WidgetController`, it defaulted to âwebâ on web, and âandroidâ everywhere else. And for methods in `KeyEventSimulator` it defaulted to âwebâ on web, and the operating system that the test was running on everywhere else. Because the operating system was based on `Platform.operatingSystem`, it usually differed from the target platform the test was running on.
AFAIK, the `platform` parameter is only meaningful for simulating `RawKeyEvent`. Once `RawKeyboard` will be fully removed, the `platform` parameter wonât be needed.
@gspencergoog In the meantime, do you think it is worth merging this fix?
## Related Issue
Fixes to https://github.com/flutter/flutter/issues/133955
## Tests
Adds one test.
## Description
This PRs changes the default value transit mode for key event simulation.
The default transit mode for key event simulation is currently `KeyDataTransitMode.rawKeyData` while on the framework side `KeyDataTransitMode.keyDataThenRawKeyData` is the preferred transit mode.
`KeyDataTransitMode.keyDataThenRawKeyData` is more accurate and can help detect issues.
For instance the following test will fail with `KeyDataTransitMode.rawKeyData` because raw keyboard logic for modifier keys is less accurate:
```dart
testWidgets('Press control left once', (WidgetTester tester) async {
debugKeyEventSimulatorTransitModeOverride = KeyDataTransitMode.keyDataThenRawKeyData;
final List<KeyEvent> events = <KeyEvent>[];
final FocusNode focusNode = FocusNode();
addTearDown(focusNode.dispose);
await tester.pumpWidget(
Focus(
focusNode: focusNode,
autofocus: true,
onKeyEvent: (_, KeyEvent event) {
events.add(event);
return KeyEventResult.handled;
},
child: Container(),
),
);
await simulateKeyDownEvent(LogicalKeyboardKey.controlLeft);
// This will fail when transit mode is KeyDataTransitMode.rawKeyData
// because a down event for controlRight is synthesized.
expect(events.length, 1);
debugKeyEventSimulatorTransitModeOverride = null;
});
```
And the following this test is ok with `KeyDataTransitMode.rawKeyData` but rightly fails with `KeyDataTransitMode.keyDataThenRawKeyData`:
```dart
testWidgets('Simulates consecutive key down events', (WidgetTester tester) async {
debugKeyEventSimulatorTransitModeOverride = KeyDataTransitMode.rawKeyData;
// Simulating several key down events without key up in between is tolerated
// when transit mode is KeyDataTransitMode.rawKeyData, it will trigger an
// assert on KeyDataTransitMode.keyDataThenRawKeyData.
await simulateKeyDownEvent(LogicalKeyboardKey.arrowDown);
await simulateKeyDownEvent(LogicalKeyboardKey.arrowDown);
debugKeyEventSimulatorTransitModeOverride = null;
});
```
## Related Issue
Related to https://github.com/flutter/flutter/issues/143845
## Tests
Adds two tests.
Originally, my aim was just to refactor (as per usual), but while messing around with the `TableBorder.symmetric` constructor, I realized that `borderRadius` was missing!
This pull request makes a few class constructors more efficient, and it fixes#144277 by adding the missing parameter.
<br>
