Add the `--downgrade` flag to the flutter/packages analyze test, so that it won't get the latest version of dependencies, avoiding out-of-band failures in flutter/flutter due to package publishing events.
Fixes https://github.com/flutter/flutter/issues/129633
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")
Manual roll is needed because incoming dart sdk requires updated version
vm_snapshot_analysis (>=0.7.4).
5ae09b8b4f...7c83ea3e85
```
7c83ea3e85 Reland "Manual roll Dart SDK from 2d98d9e27dae to 0b07debd5862 (21 revisions) (#43457)" (#43472)
9ef3e8d533 Roll Skia from 5eba922297bb to 93c92f97f5ab (2 revisions) (#43471)
```
Remove implementation of SuitePlatform from the test as well. Remove use
of fake cwd from SuitePlatform as it can't be properly faked.
## FlutterTimeline
Add a new class `FlutterTimeline` that's a drop-in replacement for `Timeline` from `dart:developer`. In addition to forwarding invocations of `startSync`, `finishSync`, `timeSync`, and `instantSync` to `dart:developer`, provides the following extra methods that make is easy to collect timings for code blocks on a frame-by-frame basis:
* `debugCollect()` - aggregates timings since the last reset, or since the app launched.
* `debugReset()` - forgets all data collected since the previous reset, or since the app launched. This allows clearing data from previous frames so timings can be attributed to the current frame.
* `now` - this was enhanced so that it works on the web by calling `window.performance.now` (in `Timeline` this is a noop in Dart web compilers).
* `collectionEnabled` - a field that controls whether `FlutterTimeline` stores timings in memory. By default this is disabled to avoid unexpected overhead (although the class is designed for minimal and predictable overhead). Specific benchmarks can enable collection to report to Skia Perf.
## Semantics benchmarks
Add `BenchMaterial3Semantics` that benchmarks the cost of semantics when constructing a screen full of Material 3 widgets from nothing. It is expected that semantics will have non-trivial cost in this case, but we should strive to keep it much lower than the rendering cost. This is the case already. This benchmark shows that the cost of semantics is <10%.
Add `BenchMaterial3ScrollSemantics` that benchmarks the cost of scrolling a previously constructed screen full of Material 3 widgets. The expectation should be that semantics will have trivial cost, since we're just shifting some widgets around. As of today, the numbers are not great, with semantics taking >50% of frame time, which is what prompted this PR in the first place. As we optimize this, we want to see this number improve.
Automatic CI testing runs on monorepo bots that tests the heads
of the Dart SDK, Flutter engine, and Flutter framework together.
These tests previously ran on bots called HHH (triple-headed),
and the logic for detecting this used the machine name of the test machine.
Extend that detection logic to cover the test machine hostnames that
run monorepo testing, that start with either 'dart-tests-' or 'luci-dart-'.
None of the machines used to run Flutter release builds have names
like this, even though they are in an internal Dart luci project.
Bug: b/231927187
- Bumps `vm_service` from `11.6.0` to `11.7.1`
- Bumps `web` from `0.1.3-beta` to `0.1.4-beta` and adds it everywhere.
- Moves `js` from `dependencies` to `dev_dependencies`
1. Add iOS and macOS migration to mark "last upgraded" Xcode version to 14.3 to prevent `Update to recommended settings` warning.
2. Update iOS and macOS templates to same.
3. Update iOS template to set `BuildIndependentTargetsInParallel` to YES as suggested. I didn't add a migration for this since it seems like a minor optimization and I don't think it's worth a potentially botched/corrupted migration.
4. Run all example/integration test project to see migrator work.
5. Add some missing test projects to the build shard since I noticed they were missing and I had to build those manually outside `SHARD=build_tests`.
Fixes https://github.com/flutter/flutter/issues/125817
See https://github.com/flutter/flutter/pull/90304 for Xcode 13 example.
This PR updates the dartdoc version to v6.2.2.
Release notes: https://github.com/dart-lang/dartdoc/releases/tag/v6.2.2
The main impact for Flutter is to update dartdoc to add chips to class and/or mixin pages for class modifiers. See dart-lang/dartdoc#3391, dart-lang/dartdoc#3402. This will also be a cherry-pick candidate for 3.1 if it can land in time.
- [ test-exempt ] I added new tests to check the change I am making, or this PR is [test-exempt].
Use the pub cache resolved by pub itself.
To add packages to the flutter.zip download they are packaged as tar.gz and added to the pub-cache on first run by using `pub cache preload`.
In preparation for the merge of flutter/plugins into flutter/packaegs,
update the cross-repo analysis to flutter/packages rather than
flutter/plugins.
The flutter_plugins.version file is left intentionally for now to avoid
issues with the roller; it will be removed when the roller has been
updated to roll the other repository.
Fixes#117659
It turns out this was due to the output-suppression timer introduced
recently as part of cleaning up the output (#109206); on success, the
script would wait 10 minutes for the timeout to expire. This didn't
affect CI because this feature doesn't apply in CI (as detected by
lack of color on stdout.)
Fix the issue by cleaning up the timer on success in the same way
as on failure.
While here, clean up the final summary messages slightly,
and also cut the trailing space that printProgress was leaving
on each line.
* [Flutter_tools] Ensure service worker starts caching assets since the first launch
* [flutter_tools] add comment to give some context on self.clients.claim()
* [flutter_tools] add comment to give some context on self.clients.claim()
Update test expectations from application/javascript -> text/javascript
`package:mime` now uses `text/javascript` and not `application/javascript`.
See https://github.com/dart-lang/mime/pull/76.
See https://datatracker.ietf.org/doc/html/rfc9239.
> This document defines equivalent processing requirements for the various script media types. The most widely supported media type in use is `text/javascript`; all others are considered historical and obsolete aliases of `text/javascript`.
* Fix screenshot testing for flutter web integration_test
* update packages
* fix method signature and todo
* Run tests on CI
* fix type
* remove silences
* Add docs
* fix comment
* fix whitespace
* review comments
* cacheWidth cacheHeight support for web canvaskit
* comments
* clarifying comment for loadTestImageProvider class
Co-authored-by: alanwutang11 <alpwu@google.com>
* isCanvasKit implement and test
* isCanvasKit implement and test
* ++
* forgot license
* make isCanvasKit a getter
* addressed comments
* forgot to change names of integration test files
* typo
* simplified tests
* comments
* Roll Flutter Engine from 67254d6e4b03 to 8d83b98c55b3
* Roll Dart SDK from 35a9facce191 to e517487c5679 (Dart 3.0) (#38105)
* Bump SDK versions.
* Bump Dart SDK version constraints
* Update shrine package to 2.0.1 (null safe version)
* Fix more tests.
* Include patches from Jason for min android sdk version
* Fix analyzer warning
* Generate local metadata even when not publishing.
For SLSA compliance we need to separate the fetch, compile and upload
steps of release artifacts. Translating this to the packaging workflows
the fetch step will checkout the prepare_package script at main ToT, the
compile step generate the bundle archives and the recipes will upload
the artifact bundles as part of the upload stage.
This change adds functionality to generate both the release bundle and
the updated metadata file in a way that both files can be uploaded as
part of the upload stage.
Bug: https://github.com/flutter/flutter/issues/115487
* Address comments.
* Update tests.
Roll dependendencies
This rolls depdendencies to latest using
flutter update-packages --force-upgrade
This change includes three code changes:
* Removes charcode from the dependencies allowlist since it no longer
appears in the transitive closure of dependencies of the flutter,
flutter_test, flutter_driver, flutter_localizations, and
integration_test packages.
* Uses Resolver.create instead of the deprecated Resolver constructor.
The default Resolver constructor has been deprecated in favour of the
static Resolver.create() factory function, which unfortunately happens
to be async. Propagated the async-ness up the chain.
This change was partially reverted and the deprecation ignored in this
patch until package:coverage can be rolled internally at Google.
* Eliminates the use of the deprecated packagesPath parameter to
HitMap.parseJson. This parameter was deprecated and replaced with
packagePath in https://github.com/dart-lang/coverage/pull/370 which
was part of the overall deprecation of the .packages file in Dart
itself https://github.com/dart-lang/sdk/issues/48272. The overall goal
being that end-user code shouldn't need to know about implementation
details such as whether dependency information is stored in a
.packages file or a package_info.json file, but rather use the
package_config package to obtain the package metadata and perform
other functions such as resolving its dependencies to filesystem
paths. packagesPath was replaced by packagePath, which takes the path
to the package directory itself. Internally, package:coverage then
uses package_config to do the rest of the package/script URI
resolution to filesystem paths.
This change was partially reverted and the deprecation ignored in this
patch until package:coverage can be rolled internally at Google.
This is a pre-update prior to updating flutter_template_images in
https://github.com/flutter/flutter/pull/103739
Issue: https://github.com/flutter/flutter/issues/103371
Issue: https://github.com/flutter/flutter/issues/103775
Issue: https://github.com/flutter/flutter/issues/103830
When re-applying the partially-reverted changes to code coverage,
we'll need to patch host_entrypoint.dart internally to await the Future
that we'll be returning rather than a non-async value.
When I added localizations for shortcut keys, I added some that actually can't be shortcut keys, so I'm removing them again. These are mostly Japanese-specific keys that don't even appear on modern keyboards for the most part.
Also, added menuBarMenuLabel for an accessibility label for menu bar menus.
I modified the code for the localization generation scripts to add a --remove-undefined flag that will remove any localizations that don't appear in the canonical locale.
Engine roll is blocked because the analysis script has been timing out trying to run the snippets tool, but only on Cirrus bots. This changes the timeout to 5 minutes from 30 seconds.
Updates the platform shims in dev/manual_tests so that Windows and Linux can be built. I had to update the Windows shims, because I was unable to build a Windows app there.
Also updates the analyze.dart script to report all license issues simultaneously instead of just dying after the first failure.
The only substantive code changes are in dev/bots/analyze.dart and dev/bots/test/analyze_test.dart
Increased the memory size of multiple_flutters to help identify regressions in performance
This is not a regression and will affect benchmark's readings.
Makes the android_semantics_testing test not fail for newer versions of Talkback.
Also, since the test now depends on pub_semver, upgraded the pubspec files.
The only substantive changes in the PR are in dev/integration_tests/android_semantics_testing/test_driver/main_test.dart
This change updates the platform runners in the benchmarks subdir.
I've attempted to replace the entire group with new code as if the project were recreated with flutter create so that they don't become a Frankenstein of minor changes to make it work again, but just plain old generated code that can be replaced and updated in place.
This fixes an issue with the Dart Head-Head-Head CI bot, where it was seeing failures because of concurrent execution of the snippets tool.
It adds a single run of the snippets tool right after activation to force the compiling of the package executable, which is what has trouble with concurrent invocation.
This is a temporary measure until dart pub global run is fixed.
This does a cleanup of the examples, removing all of the "section" markers and extra comments that we don't need anymore now that the samples are no longer in the source code. It also removes the --template arguments from the {@tool dartpad} and {@tool sample} directives, since those are no longer used. It converts two examples that I discovered were still embedded into linked examples in the examples folder.
I didn't delete the templates from the snippets config folder yet, because there are still embedded samples in the dart:ui package from the engine that use them. Once dart:ui no longer uses the templates, they can be removed.
I bumped the version of the snippets package to pick up a change that allows removal of the --template argument.
This adds a smoke test for every single API example. It also fixes 17 tests that had bugs in them, or were otherwise broken, and even fixes one actual bug in the framework, and one limitation in the framework.
The bug in the framework is that NetworkImage's _loadAsync method had await response.drain<List<int>>();, but if the response is null, it will throw a cryptic exception saying that Null can't be assigned to List<int>. The fix was just to use await response.drain<void>(); instead.
The limitation is that RelativePositionedTransition takes an Animation<Rect> rect parameter, and if you want to use a RectTween with it, the value emitted there is Rect?, and one of the examples was just casting from Animation<Rect> to Animation<Rect?>, which is invalid, so I modified RelativePositionedTransition to take a Rect? and just use Rect.zero if the rect is null.
