- 12 Mar, 2024 1 commit
-
-
Michael Goderbauer authored
Reverts flutter/flutter#144970 No changes in this PR compared to the original. The test failure was fixed by adding missing awaits in https://github.com/flutter/flutter/pull/144978. Fixes https://github.com/flutter/flutter/issues/144353.
-
- 11 Mar, 2024 3 commits
-
-
auto-submit[bot] authored
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. ```
-
Michael Goderbauer authored
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. ```
-
Nate authored
Based on issue #144903, this PR aims to bring the codebase more in line with the [Flutter repo style guide](https://github.com/flutter/flutter/wiki/Style-guide-for-Flutter-repo#avoid-using-if-chains-or--or--with-enum-values): > #### Avoid using `if` chains or `?:` or `==` with enum values <br> This change unfortunately increases the total line length, but it also improves readability.
-
- 07 Mar, 2024 2 commits
-
-
Bruno Leroux authored
## 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.
-
Bruno Leroux authored
## 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.
-
- 04 Mar, 2024 1 commit
-
-
Nate authored
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>
-
- 26 Feb, 2024 1 commit
-
-
Polina Cherkasova authored
Contributes to https://github.com/dart-lang/leak_tracker/issues/218
-
- 23 Feb, 2024 1 commit
-
-
Nate authored
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.
-
- 22 Feb, 2024 1 commit
-
-
Derek Xu authored
This PR implements the functionality described above and hides it behind the `--experimental-faster-testing` flag of `flutter test`. ### The following are some performance measurements from test runs conducted on GitHub Actions run 1 logs: https://github.com/derekxu16/flutter_test_ci/actions/runs/8008029772/attempts/1 run 2 logs: https://github.com/derekxu16/flutter_test_ci/actions/runs/8008029772/attempts/2 run 3 logs: https://github.com/derekxu16/flutter_test_ci/actions/runs/8008029772/attempts/3 **length of `flutter test --reporter=expanded test/animation test/foundation` step** run 1: 54s run 2: 52s run 3: 56s average: 54s **length of `flutter test --experimental-faster-testing --reporter=expanded test/animation test/foundation` step** run 1: 27s run 2: 27s run 3: 29s average: 27.67s (~48.77% shorter than 54s) **length of `flutter test --reporter=expanded test/animation test/foundation test/gestures test/painting test/physics test/rendering test/scheduler test/semantics test/services` step** run 1: 260s run 2: 270s run 3: 305s average: 278.33s **length of `flutter test --experimental-faster-testing --reporter=expanded test/animation test/foundation test/gestures test/painting test/physics test/rendering test/scheduler test/semantics test/services` step** from a clean build (right after deleting the build folder): run 1: 215s run 2: 227s run 3: 245s average: 229s (~17.72% shorter than 278.33s) Note that in reality, `test/material` was not passed to `flutter test` in the trials below. All of the test files under `test/material` except for `test/material/icons_test.dart` were listed out individually **length of `flutter test --reporter=expanded test/material` step** run 1: 408s run 2: 421s run 3: 451s average: 426.67s **length of `flutter test --experimental-faster-testing --reporter=expanded test/material` step** run 1: 382s run 2: 373s run 3: 400s average: 385s (~9.77% shorter than 426.67s) --------- Co-authored-by: Dan Field <dnfield@google.com>
-
- 16 Feb, 2024 1 commit
-
-
Michael Goderbauer authored
Fixes https://github.com/flutter/flutter/issues/143405. It was counter-intuitive that a SemanticsFinder without specifying a FlutterView would only search the nodes in the default view. This change makes it so that when no view is specified the semantics trees of all known FlutterViews are searched.
-
- 15 Feb, 2024 2 commits
-
-
Kate Lovett authored
Relands https://github.com/flutter/flutter/pull/143386 Which was reverted in https://github.com/flutter/flutter/pull/143523 Fixes https://github.com/flutter/flutter/issues/143173 Unblocks https://github.com/flutter/flutter/pull/143485 â â¡ï¸ Update from the revert is in this commit: https://github.com/flutter/flutter/pull/143527/commits/1e6853291eba42ee7005f284265118be33c99673
-
auto-submit[bot] authored
Reverts flutter/flutter#143386 Initiated by: Piinks Reason for reverting: This broke a customer test. Original PR Author: Piinks Reviewed By: {goderbauer} This change reverts the following previous change: Original Description: Fixes https://github.com/flutter/flutter/issues/143173 The `start` and `end` parameters of `SemanticsController.simulatedAccessibilityTraversal` were deprecated in https://github.com/flutter/flutter/issues/112413, but no tests were added that verified the new API.
This change - fixes a typo in an error message - fixes the new `startNode` and `endNode` not being accounted for in setting the traversal range - adds dart fixes for the deprecations - adds tests for the new API that is meant to replace the deprecated one. - Filed https://github.com/flutter/flutter/issues/143405 to follow up on the new API not working in multiple views.
-
- 14 Feb, 2024 2 commits
-
-
Michael Goderbauer authored
Follow-up to https://github.com/flutter/flutter/pull/143347.
-
Kate Lovett authored
Fixes https://github.com/flutter/flutter/issues/143173 The `start` and `end` parameters of `SemanticsController.simulatedAccessibilityTraversal` were deprecated in https://github.com/flutter/flutter/issues/112413, but no tests were added that verified the new API. ð³ This change - fixes a typo in an error message - fixes the new `startNode` and `endNode` not being accounted for in setting the traversal range - adds dart fixes for the deprecations - adds tests for the new API that is meant to replace the deprecated one. - Filed https://github.com/flutter/flutter/issues/143405 to follow up on the new API not working in multiple views.
-
- 09 Feb, 2024 1 commit
-
-
Kris Pypen authored
During golden test image comparison 2 lists of a different type are compared with the method "identical", so this will never be true. The test image is a _Uint8ArrayView while the master image is an Uint8List. So that results in always a heavy computation to get the difference between the test and the master image. When you run this test snippet I go from 51 seconds to 14 seconds: ```dart import 'package:flutter/material.dart'; import 'package:flutter_test/flutter_test.dart'; void main() { for (int i = 0; i < 100; i++) { testWidgets('Small test', (WidgetTester tester) async { await tester.pumpWidget(Directionality(textDirection: TextDirection.ltr, child: Text('jo'))); await expectLater(find.byType(Text), matchesGoldenFile('main.png')); }); } } ```
-
- 07 Feb, 2024 2 commits
-
-
Valentin Vignal authored
Fixes https://github.com/flutter/flutter/issues/141036
-
Andrew Brampton authored
Update the `matchesGoldenFile()` / `LocalComparisonOutput` code to generate failure images for golden tests that fail when the image sizes do not match. This can make it far quicker to identify what is wrong with the test image. Fixes https://github.com/flutter/flutter/issues/141488 - [ x I read and followed the [Flutter Style Guide], including [Features we expect every widget to implement].
-
- 30 Jan, 2024 1 commit
-
-
Aizat Azhar authored
Reset `framesEnabled` to `true` at the end of each test as otherwise subsequent tests may fail when pumping a widget Fixes #141835
-
- 26 Jan, 2024 3 commits
-
-
Michael Goderbauer authored
Reverts flutter/flutter#142339 In the original change one of the tests included the same view twice which resulted in a different failure than the expected one. The second commit contains the fix for this. I don't understand how this wasn't caught presubmit on CI.
-
auto-submit[bot] authored
Reverts flutter/flutter#141484 Initiated by: eliasyishak This change reverts the following previous change: Original Description: The existing `runApp` bootstraps the widget tree and renders the provided widget into the default view (which is currently the implicit View from `PlatformDispatcher.implicitView` and - in the future - may be a default-created window). Apps, that want more control over the View they are rendered in, need a new way to bootstrap the widget tree: `runWidget`. It does not make any assumptions about the View the provided widget is rendered into. Instead, it is up to the caller to include a View widget in the provided widget tree that specifies where content should be rendered. In the future, this may enable developers to create a custom window for their app instead of relying on the default-created one.
-
Michael Goderbauer authored
The existing `runApp` bootstraps the widget tree and renders the provided widget into the default view (which is currently the implicit View from `PlatformDispatcher.implicitView` and - in the future - may be a default-created window). Apps, that want more control over the View they are rendered in, need a new way to bootstrap the widget tree: `runWidget`. It does not make any assumptions about the View the provided widget is rendered into. Instead, it is up to the caller to include a View widget in the provided widget tree that specifies where content should be rendered. In the future, this may enable developers to create a custom window for their app instead of relying on the default-created one.
-
- 19 Jan, 2024 2 commits
-
-
Michael Goderbauer authored
Much nicer calling API and simplifies evolving this API in the future. I wish we could write a dart fix for this, but that's blocked on https://github.com/dart-lang/sdk/issues/54668.
-
fzyzcjy authored
The old doc says that, AutomatedTestWidgetsFlutterBinding for `flutter test` and LiveTestWidgetsFlutterBinding for `flutter run`. However, suppose we `flutter test integration_test/simple_test.dart` with the following code: ``` void main() { testWidgets('hi', (WidgetTester tester) async { print('hi ${TestWidgetsFlutterBinding.instance} ${Platform.operatingSystem}'); }); } ``` We will see: `hi <IntegrationTestWidgetsFlutterBinding> ios`. Therefore, we see `IntegrationTestWidgetsFlutterBinding` is used in a `flutter test` command, which is contrary to the documentation.
-
- 16 Jan, 2024 1 commit
-
-
Polina Cherkasova authored
-
- 12 Jan, 2024 1 commit
-
-
Anis Alibegić authored
Fair amount of typos spotted and fixed. Some of them are in comments, some of them are in code and some of them are in nondart files. There is no need for issues since it's a typo fix. I have doubts about [packages/flutter_tools/lib/src/ios/core_devices.dart](https://github.com/flutter/flutter/compare/master...anisalibegic:flutter:master#diff-fdbc1496b4bbe7e2b445a567fd385677af861c0093774e3d8cc460fdd5b794fa), I have a feeling it might broke some things on the other end, even though it's a typo.
-
- 09 Jan, 2024 1 commit
-
-
Michael Goderbauer authored
This reverts commit https://github.com/flutter/flutter/commit/d24c01bd0c41331bd17165e0173b24c5d05d7c0a. The original change was reverted because it caused some apps to get stuck on the splash screen on some phones. An investigation determined that this was due to a rounding error. Example: The device reports a physical size of 1008.0 x 2198.0 with a dpr of 1.912500023841858. Flutter would translate that to a logical size of 527.0588169589221 x 1149.2810314243163 and use that as the input for its layout algorithm. Since the constraints here are tight, the layout algorithm would determine that the resulting logical size of the root render object must be 527.0588169589221 x 1149.2810314243163. Translating this back to physical pixels by applying the dpr resulted in a physical size of 1007.9999999999999 x 2198.0 for the frame. Android now rejected that frame because it didn't match the expected size of 1008.0 x 2198.0 and since no frame had been rendered would never take down the splash screen. Prior to dynamically sized views, this wasn't an issue because we would hard-code the frame size to whatever the requested size was. Changes in this PR over the original PR: * The issue has been fixed now by constraining the calculated physical size to the input physical constraints which makes sure that we always end up with a size that is acceptable to the operating system. * The `ViewConfiguration` was refactored to use the slightly more convenient `BoxConstraints` over the `ViewConstraints` to represent constraints. Both essentially represent the same thing, but `BoxConstraints` are more powerful and we avoid a couple of translations between the two by translating the` ViewConstraints` from the `FlutterView` to `BoxConstraints` directly when the `ViewConfiguration` is created. All changes over the original PR are contained in the second commit of this PR. Fixes b/316813075 Part of https://github.com/flutter/flutter/issues/134501.
-
- 04 Jan, 2024 1 commit
-
-
Polina Cherkasova authored
-
- 03 Jan, 2024 2 commits
-
-
auto-submit[bot] authored
Reverts flutter/flutter#140521 Initiated by: zanderso This change reverts the following previous change: Original Description: Original PR: https://github.com/flutter/flutter/pull/138057 Revert: https://github.com/flutter/flutter/pull/140502 Issue: https://ci.chromium.org/ui/p/flutter/builders/prod/Linux_android%20flutter_test_performance/12787/overview Exception: flutter test rendered unexpected output (1 bad lines) Explanation: leak tracker adds tear down even when there is no leak tracking, because at the moment of adding tear down it is unclear if leak tracking will be used for some tests. Fix: add enabling flag for leak tracker and make creation of tear down conditional. Prerequisites:
-
Polina Cherkasova authored
-
- 21 Dec, 2023 2 commits
-
-
Jim Graham authored
The PR is breaking the `flutter_test_performance` test and making the tree red.
-
Polina Cherkasova authored
Contributes to: https://github.com/flutter/flutter/issues/135856 TODO:
-
- 20 Dec, 2023 4 commits
-
-
Michael Goderbauer authored
These were not ignoring anything (anymore).
-
LongCatIsLooong authored
Extracted from https://github.com/flutter/flutter/pull/139717 as-is. Landing this change first so we can avoid doing a g3fix.
-
auto-submit[bot] authored
Reverts flutter/flutter#139717 Initiated by: LongCatIsLooong This change reverts the following previous change: Original Description: Fixes https://github.com/flutter/flutter/issues/131435, #104594, #43400 Needs https://github.com/flutter/engine/pull/48774 (to fix the web test failure). Currently the method we use for text span hit testing `TextPainter.getPositionForOffset` always returns the closest `TextPosition`, even when the given offset is far away from the text. The new TextPaintes method tells you the layout bounds (`width = letterspacing / 2 + x_advance + letterspacing / 2`, `height = font ascent + font descent`) of a character, the PR changes the hit testing implementation such that a TextSpan is only considered hit if the point-down event landed in one of it's character's layout bounds. Potential issues: 1. In theory since the text is baseline aligned, we should use the max ascent and max descent of each character to calculate the height of the text span's hit-test region, in case some characters in the span have to fall back to a different font, but that will be slower and it typically doesn't make a huge difference. This is a breaking change. It also introduces a new finder and a new method `WidgetTester.tapOnText`: `await tester.tapOnText('string to match')` for ease of migration.
-
LongCatIsLooong authored
Fixes https://github.com/flutter/flutter/issues/131435, #104594, #43400 Needs https://github.com/flutter/engine/pull/48774 (to fix the web test failure). Currently the method we use for text span hit testing `TextPainter.getPositionForOffset` always returns the closest `TextPosition`, even when the given offset is far away from the text. The new TextPaintes method tells you the layout bounds (`width = letterspacing / 2 + x_advance + letterspacing / 2`, `height = font ascent + font descent`) of a character, the PR changes the hit testing implementation such that a TextSpan is only considered hit if the point-down event landed in one of it's character's layout bounds. Potential issues: 1. In theory since the text is baseline aligned, we should use the max ascent and max descent of each character to calculate the height of the text span's hit-test region, in case some characters in the span have to fall back to a different font, but that will be slower and it typically doesn't make a huge difference. This is a breaking change. It also introduces a new finder and a new method `WidgetTester.tapOnText`: `await tester.tapOnText('string to match')` for ease of migration.
-
- 14 Dec, 2023 1 commit
-
-
Lau Ching Jun authored
Reverts flutter/flutter#138648 This caused the app to be stuck in the splash screen on certain phone models. Context: b/316244317
-
- 11 Dec, 2023 3 commits
-
-
Greg Spencer authored
## Description This starts the deprecation of the `RawKeyEvent`/`RawKeyboard` event system that has been replaced by the `KeyEvent`/`HardwareKeyboard` event system. Migration guide is available here: https://docs.flutter.dev/release/breaking-changes/key-event-migration ## Related Issues - https://github.com/flutter/flutter/issues/136419 ## Related PRs - https://github.com/flutter/website/pull/9889
-
Bartek Pacia authored
This PR adds `String? identifier` to `Semantics` and `SemanticsProperties`. The `identifier` will be exposed on Android as `resource-id` and on iOS as `accessibilityIdentifier`. Mainly targeted at #17988 Initial Engine PR with Android support: https://github.com/flutter/engine/pull/47961 iOS Engine PR: https://github.com/flutter/engine/pull/48858 ### Migration This change breaks the SemanticsUpdateBuilder API which is on the Framework<-->Engine border. For more details see [engine PR](https://github.com/flutter/engine/pull/47961). Steps: part 1: [engine] add `SemanticsUpdateBuilderNew` https://github.com/flutter/engine/pull/47961 **part 2: [flutter] use `SemanticsUpdateBuilderNew`** <-- we are here part 3: [engine] update `SemanticsUpdateBuilder` to be the same as `SemanticsUpdateBuilderNew`* part 4: [flutter] use (now updated) `SemanticsUpdateBuilder` again. part 5: [engine] remove `SemanticsBuilderNew`
-
hgraceb authored
The previous test for #128137 does not effectively regress and verify #123313 because the issue is specific to desktop platforms.
-