## 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.
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.
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.
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.
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.
* Added `performAction` to `SemanticsController` as well as specific methods for specific actions
* Added a `scrollable` finder to `find.semantics` as a convenience method for `findAny(<all scrollable actions>)`
* Updated `containsSemantics` and `matchSemantics` matchers to also work on `FinderBase<Semantics>`
Closes#112413
Updates references to `finders.dart` in `controller.dart` to use a namespace. This enables us to make use of `finders.dart#find` in `SemanticsController` without anything being shadowed.
Fixes#136421
## Description
This removes all of the comments that are of the form "so-and-so must not be null" or "so-and-so must be non-null" from the cases where those values are defines as non-nullable values.
This PR removes them from the library in the repo that don't have anything to do with the framework.
This was done by hand, since it really didn't lend itself to scripting, so it needs to be more than just spot-checked, I think. I was careful to leave any comment that referred to parameters that were nullable, but I may have missed some.
In addition to being no longer relevant after null safety has been made the default, these comments were largely fragile, in that it was easy for them to get out of date, and not be accurate anymore anyhow.
This did create a number of constructor comments which basically say "Creates a [Foo].", but I don't really know how to avoid that in a large scale change, since there's not much you can really say in a lot of cases. I think we might consider some leniency for constructors to the "Comment must be meaningful" style guidance (which we de facto have already, since there are a bunch of these).
## Related PRs
- https://github.com/flutter/flutter/pull/134984
- https://github.com/flutter/flutter/pull/134991
- https://github.com/flutter/flutter/pull/134992
- https://github.com/flutter/flutter/pull/134993
## Tests
- Documentation only change.
* Pulled `FinderBase` out of `Finder`
* `FinderBase` can be used for any object, not just elements
* Terminology was updated to be more "find" related
* Re-implemented `Finder` using `FinderBase<Element>`
* Backwards compatibility maintained with `_LegacyFinderMixin`
* Introduced base classes for SemanticsNode finders
* Introduced basic SemanticsNode finders through `find.semantics`
* Updated some relevant matchers to make use of the more generic `FinderBase`
Closes#123634Closes#115874
This change enables Flutter to generate multiple Scenes to be rendered into separate FlutterViews from a single widget tree. Each Scene is described by a separate render tree, which are all associated with the single widget tree.
This PR implements the framework-side mechanisms to describe the content to be rendered into multiple views. Separate engine-side changes are necessary to provide these views to the framework and to draw the framework-generated Scene into them.
## Summary of changes
The details of this change are described in [flutter.dev/go/multiple-views](https://flutter.dev/go/multiple-views). Below is a high-level summary organized by layers.
### Rendering layer changes
* The `RendererBinding` no longer owns a single `renderView`. In fact, it doesn't OWN any `RenderView`s at all anymore. Instead, it offers an API (`addRenderView`/`removeRenderView`) to add and remove `RenderView`s that then will be MANAGED by the binding. The `RenderView` itself is now owned by a higher-level abstraction (e.g. the `RawView` Element of the widgets layer, see below), who is also in charge of adding it to the binding. When added, the binding will interact with the `RenderView` to produce a frame (e.g. by calling `compositeFrame` on it) and to perform hit tests for incoming pointer events. Multiple `RenderView`s can be added to the binding (typically one per `FlutterView`) to produce multiple Scenes.
* Instead of owning a single `pipelineOwner`, the `RendererBinding` now owns the root of the `PipelineOwner` tree (exposed as `rootPipelineOwner` on the binding). Each `PipelineOwner` in that tree (except for the root) typically manages its own render tree typically rooted in one of the `RenderView`s mentioned in the previous bullet. During frame production, the binding will instruct each `PipelineOwner` of that tree to flush layout, paint, semantics etc. A higher-level abstraction (e.g. the widgets layer, see below) is in charge of adding `PipelineOwner`s to this tree.
* Backwards compatibility: The old `renderView` and `pipelineOwner` properties of the `RendererBinding` are retained, but marked as deprecated. Care has been taken to keep their original behavior for the deprecation period, i.e. if you just call `runApp`, the render tree bootstrapped by this call is rooted in the deprecated `RendererBinding.renderView` and managed by the deprecated `RendererBinding.pipelineOwner`.
### Widgets layer changes
* The `WidgetsBinding` no longer attaches the widget tree to an existing render tree. Instead, it bootstraps a stand-alone widget tree that is not backed by a render tree. For this, `RenderObjectToWidgetAdapter` has been replaced by `RootWidget`.
* Multiple render trees can be bootstrapped and attached to the widget tree with the help of the `View` widget, which internally is backed by a `RawView` widget. Configured with a `FlutterView` to render into, the `RawView` creates a new `PipelineOwner` and a new `RenderView` for the new render tree. It adds the new `RenderView` to the `RendererBinding` and its `PipelineOwner` to the pipeline owner tree.
* The `View` widget can only appear in certain well-defined locations in the widget tree since it bootstraps a new render tree and does not insert a `RenderObject` into an ancestor. However, almost all Elements expect that their children insert `RenderObject`s, otherwise they will not function properly. To produce a good error message when the `View` widget is used in an illegal location, the `debugMustInsertRenderObjectIntoSlot` method has been added to Element, where a child can ask whether a given slot must insert a RenderObject into its ancestor or not. In practice, the `View` widget can be used as a child of the `RootWidget`, inside the `view` slot of the `ViewAnchor` (see below) and inside a `ViewCollection` (see below). In those locations, the `View` widget may be wrapped in other non-RenderObjectWidgets (e.g. InheritedWidgets).
* The new `ViewAnchor` can be used to create a side-view inside a parent `View`. The `child` of the `ViewAnchor` widget renders into the parent `View` as usual, but the `view` slot can take on another `View` widget, which has access to all inherited widgets above the `ViewAnchor`. Metaphorically speaking, the view is anchored to the location of the `ViewAnchor` in the widget tree.
* The new `ViewCollection` widget allows for multiple sibling views as it takes a list of `View`s as children. It can be used in all the places that accept a `View` widget.
## Google3
As of July 5, 2023 this change passed a TAP global presubmit (TGP) in google3: tap/OCL:544707016:BASE:545809771:1688597935864:e43dd651
## Note to reviewers
This change is big (sorry). I suggest focusing the initial review on the changes inside of `packages/flutter` first. The majority of the changes describe above are implemented in (listed in suggested review order):
* `rendering/binding.dart`
* `widgets/binding.dart`
* `widgets/view.dart`
* `widgets/framework.dart`
All other changes included in the PR are basically the fallout of what's implemented in those files. Also note that a lot of the lines added in this PR are documentation and tests.
I am also very happy to walk reviewers through the code in person or via video call, if that is helpful.
I appreciate any feedback.
## Feedback to address before submitting ("TODO")
* Revert "Remove references to BindingBase.window (#122119)"
This reverts commit c7681f00cf1fb1c63bebb27d715f29feb77b78b7.
* Revert "Remove another reference to BindingBase.window (#122341)"
This reverts commit 6ec444506375cfa94535a45c2320e01094c295e0.
* Revert "Reland (2): Removes single window assumptions from `flutter_test` (#122233)"
This reverts commit eb3d317ea06e59fadc379210f5c6e685505d8e0f.
* Revert "Remove single view assumption from TestViewConfiguration (#122352)"
This reverts commit 927289fb4e5b25a71f794bc808a8c31554859a50.
* Revert "Updates `flutter/test/cupertino` to no longer use `TestWindow` (#122325)"
This reverts commit 67e17e45f05271c6c409183c1d33806683cb9e4d.
* Revert "Updates `flutter/test/gestures` to no longer reference `TestWindow` (#122327)"
This reverts commit c2a5111cc0f9bcb104982b38a1a0a9c4210b601f.
* Revert "Updates `flutter/test/rendering` to no longer use `TestWindow` (#122347)"
This reverts commit 28b65e089b3f8e8c21572cd8a73184858b6360c3.
* Revert "Updates `flutter_localizations/test` to stop using `TestWindow` (#122321)"
This reverts commit 01367d52d7886f51a8921c9dc4a8e4c541686e98.
* Use `curly_braces_in_flow_control_structures` for `packages/flutter_driver`
* Use `curly_braces_in_flow_control_structures` for `packages/flutter_goldens`
* Use `curly_braces_in_flow_control_structures` for `packages/flutter_goldens_client`
* Use `curly_braces_in_flow_control_structures` for `packages/flutter_localizations`
* Use `curly_braces_in_flow_control_structures` for `packages/flutter_test`
* Use `curly_braces_in_flow_control_structures` for `packages/flutter_web_plugins`
* fix comments
* Use `curly_braces_in_flow_control_structures` for `packages/integration_test`
* fix indentation
