Closes https://github.com/flutter/flutter/issues/165743
### Description
- Adds `rsuperellipse` to `mock_canvas.dart` to verify
`drawRSuperellipse` calls
- Adds tests for `paints..rsuperellipse`
## Pre-launch Checklist
- [X] I read the [Contributor Guide] and followed the process outlined
there for submitting PRs.
- [X] I read the [Tree Hygiene] wiki page, which explains my
responsibilities.
- [X] I read and followed the [Flutter Style Guide], including [Features
we expect every widget to implement].
- [X] I signed the [CLA].
- [X] I listed at least one issue that this PR fixes in the description
above.
- [X] I updated/added relevant documentation (doc comments with `///`).
- [X] I added new tests to check the change I am making, or this PR is
[test-exempt].
- [X] I followed the [breaking change policy] and added [Data Driven
Fixes] where supported.
- [X] All existing and new tests are passing.
Current implementation runs timers and microtask callbacks in the root
zone. That assumes that the top-level `scheduleMicrotask` or `Timer`
constructors have been used, which have so far wrapped the callback with
`runCallbackGuarded` before calling the zone implementation.
That means that doing `zone.scheduleMicrotask` directly would not ensure
that the microtask was run in the correct zone. If a `run` handler
throws, it wouldn't be caught.
This change makes the `realAsyncZone` do whatever the root zone would do
if its `ZoneDelegate` got called with the intended zone and arguments.
That should be consistent with the current behavior, and be compatible
with incoming bug-fixes to the platform `Zone` behavior.
Prepares Flutter for landing
https://dart-review.googlesource.com/c/sdk/+/406961
which is currently blocked (so this indirectly fixes
https://github.com/dart-lang/sdk/issues/59913).
There are no new tests, the goal is that all existing tests keep
running, and that they keep doing so when the Dart CL lands. Currently
that CL only breaks one test, the
`dev/automated_tests/test_smoke_test/fail_test_on_exception_after_test.dart`
test which threw the error-after-test in the root zone instead of the
test zone. This change fixes that.
Fixes https://github.com/flutter/flutter/issues/162317
### Description
- Adds `startAngle`, `sweepAngle` and `useCenter` properties to
`_ArcPaintPredicate`
- Adds tests for `_ArcPaintPredicate`
## Pre-launch Checklist
- [X] I read the [Contributor Guide] and followed the process outlined
there for submitting PRs.
- [X] I read the [Tree Hygiene] wiki page, which explains my
responsibilities.
- [X] I read and followed the [Flutter Style Guide], including [Features
we expect every widget to implement].
- [X] I signed the [CLA].
- [X] I listed at least one issue that this PR fixes in the description
above.
- [ ] I updated/added relevant documentation (doc comments with `///`).
- [X] I added new tests to check the change I am making, or this PR is
[test-exempt].
- [X] I followed the [breaking change policy] and added [Data Driven
Fixes] where supported.
- [X] All existing and new tests are passing.
Co-authored-by: Tong Mu <dkwingsmt@users.noreply.github.com>
- Delete code paths that handle screenshots for the HTML renderer
- Delete artifact enums for the HTML/AUTO renderers (and all their
usages).
- Remove HTML/AUTO renderers warnings.
- Delete the HTML/AUTO renderer enums (and all their usages).
- Delete tests for all the above.
Powered by the new and amazing `unnecessary_ignore` lint.
We're not enabling this lint by default because being able to
temporarily use ignores that don't ignore anything is a powerful tool to
enable migrations. We should turn this lint on locally periodically,
though, and clean up all outdated ignores.
- Cleanup many HTML special cases and skips in framework tests.
- Update some dartdocs that referred to the HTML renderer.
For reviewers: it may help if you set `Hide whitespace` to true in
Github. It will help you skip through all the formatting/indentation
changes.
Towards https://github.com/flutter/flutter/issues/160261.
This is a PR and proposal all-in-one to deprecate, and remove, pending
the removal of the HTML backend, `WebGoldenComparator` (and related
symbols, `webGoldenComparator` and `DefaultWebGoldenComparator`).
The concept of `WebGoldenComparator` was added because the HTML-based
renderer could not support the `GoldenFileComparator` contract:
7141c2a136/packages/flutter_test/lib/src/_matchers_web.dart (L105-L108)
Once the Skia renderer (and now, SkWasm renderer) were added, it was now
possible to support the same API used by the native engine(s). This PR
conditionally, if _not_ using the HTML renderer, uses
`goldenFileComparator` instead, which re-uses the same code that
previously backed `DefaultWebGoldenFileComparator`.
No _new_ logic has been introduced in this change. This might need an
iteration or two to get right.
Feedback welcome!
dart_style 3.0.1 comes with some minor style fixes:
https://github.com/dart-lang/dart_style/blob/main/CHANGELOG.md#301
This PR applies this fixes in bulk across the repository. (Otherwise,
the next person touching these files would have been the one updating
them to the new format by running the formatter).
This auto-formats all *.dart files in the repository outside of the
`engine` subdirectory and enforces that these files stay formatted with
a presubmit check.
**Reviewers:** Please carefully review all the commits except for the
one titled "formatted". The "formatted" commit was auto-generated by
running `dev/tools/format.sh -a -f`. The other commits were hand-crafted
to prepare the repo for the formatting change. I recommend reviewing the
commits one-by-one via the "Commits" tab and avoiding Github's "Files
changed" tab as it will likely slow down your browser because of the
size of this PR.
---------
Co-authored-by: Kate Lovett <katelovett@google.com>
Co-authored-by: LongCatIsLooong <31859944+LongCatIsLooong@users.noreply.github.com>
When running `dart format` over these lines the `// ignore` ended up on
a line where it wasn't properly ignoring the lint. This adjusts the
placement of `// ignore`s so they will continue to ignore the right
thing even after the code is auto formatted.
I am hoping that if we do this now the large PR that formats the entire
repo will go in smoother without manual intervention.
## 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.
