Some of these request paths are not guaranteed to be requested by the
time the test is finished, which makes this test somewhat flaky. We
don't really care about verifying these requests specifically anyway, so
just don't track them or compare them to our expectations.
This fixes https://github.com/flutter/flutter/issues/171025
This PR is an attempt to reland
https://github.com/flutter/flutter/pull/168996
There were some issues that cropped up in the `web_long_running_test`
shards. However, it turns out that these tests don't actually run in
presubmit on any PR that has any engine changes, which is not ideal. I
modified the long running tests to run in presubmit, but this had issues
because apparently a big chunk of these integration tests actually are
trying to download canvaskit from CDN. I changed almost all of the tests
to use local canvaskit (which should make them more reliable and
hermetic). There is one test whose job is to actually test the CDN
itself, and I am leaving that disabled in presubmit for PRs that have
engine changes (since the engine artifacts won't be uploaded to CDN yet)
but the rest of them are all running and passing now.
Also, I fixed the underlying issue that was exposed by the long running
tests, which is that the CanvasKit path clipping stuff in the layer
visitor needs to be aware of LazyPath.
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>
This makes several changes to flutter web app bootstrapping.
* The build now produces a `flutter_bootstrap.js` file.
* By default, this file does the basic streamlined startup of a flutter app with the service worker settings and no user configuration.
* The user can also put a `flutter_bootstrap.js` file in the `web` subdirectory in the project directory which can have whatever custom bootstrapping logic they'd like to write instead. This file is also templated, and can use any of the tokens that can be used with the `index.html` (with the exception of `{{flutter_bootstrap_js}}`, see below).
* Introduced a few new templating tokens for `index.html`:
* `{{flutter_js}}` => inlines the entirety of `flutter.js`
* `{{flutter_service_worker_version}}` => replaced directly by the service worker version. This can be used instead of the script that sets the `serviceWorkerVersion` local variable that we used to have by default.
* `{{flutter_bootstrap_js}}` => inlines the entirety of `flutter_bootstrap.js` (this token obviously doesn't apply to `flutter_bootstrap.js` itself).
* Changed `IndexHtml` to be called `WebTemplate` instead, since it is used for more than just the index.html now.
* We now emit warnings at build time for certain deprecated flows:
* Warn on the old service worker version pattern (i.e.`(const|var) serviceWorkerVersion = null`) and recommends using `{{flutter_service_worker_version}}` token instead
* Warn on use of `FlutterLoader.loadEntrypoint` and recommend using `FlutterLoader.load` instead
* Warn on manual loading of `flutter_service_worker.js`.
* The default `index.html` on `flutter create` now uses an async script tag with `flutter_bootstrap.js`.
I previously made a PR (#136140) that used `switch` expressions to make some parts of the Flutter codebase easier to understand. It was assigned to the framework team, and @christopherfujino let me know that it was too large to effectively review and recommended breaking it up into smaller pull requests.
Here's a PR that only targets files in the `dev/` directory. Hopefully this will be easier to work with!
(solves issue https://github.com/flutter/flutter/issues/136139)
## Description
This PR adds a `nonce` parameter to flutter.js' `loadEntrypoint` method.
When set, loadEntrypoint will add a `nonce` attribute to the `main.dart.js` script tag, which allows Flutter to run in environments slightly more restricted by CSP; those that don't add `'self'` as a valid source for `script-src`.
----
### CSP directive
After this change, the CSP directive for a Flutter Web index.html can be:
```
script-src 'nonce-YOUR_NONCE_VALUE' 'wasm-unsafe-eval';
font-src https://fonts.gstatic.com;
style-src 'nonce-YOUR_NONCE_VALUE';
```
When CSP is set via a `meta` tag (like in the test accompanying this change), and to use a service worker, the CSP needs an additional directive: [`worker-src 'self';`](https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Content-Security-Policy/worker-src)
When CSP set via response headers, the CSP that applies to `flutter_service_worker.js` is determined by its response headers. See **Web Workers API > [Content security policy](https://developer.mozilla.org/en-US/docs/Web/API/Web_Workers_API/Using_web_workers#content_security_policy)** in MDN.)
----
### Initialization
If the CSP is set to disallow `script-src 'self'`, a nonce needs to also be passed to `loadEntrypoint`:
```javascript
_flutter.loader.loadEntrypoint({
nonce: 'SOME_NONCE',
onEntrypointLoaded: (engineInitializer) async {
const appRunner = await engineInitializer.initializeEngine({
nonce: 'SOME_NONCE',
});
appRunner.runApp();
},
});
```
(`nonce` shows twice for now, because the entrypoint loader script doesn't have direct access to the `initializeEngine` call.)
----
## Tests
* Added a smoke test to ensure an app configured as described above starts.
## Issues
* Fixes https://github.com/flutter/flutter/issues/126977
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()
