commit | 58d0f1accd7694d19a5fa71661aec8aec90b6d68 | [log] [tgz] |
---|---|---|
author | Nate Chapin <japhet@chromium.org> | Fri Feb 17 18:38:03 2023 |
committer | Blink WPT Bot <blink-w3c-test-autoroller@chromium.org> | Fri Feb 17 18:53:49 2023 |
tree | cdae131b3d5aa17854462b8fd88bfd7d5064a108 | |
parent | 5ea81da98156f7f5426af6fbc623674c9a252842 [diff] |
Allow the navigate event to cancel same-document main-frame traversals Currently, the navigate event is allowed to cancel push/replace/reload navigations, but not traversals. There are two reasons for this: chromium's architecture made it difficult to support cancelation without getting out of sync with the authoritative version of the joint session history in the browser process, and we were concerned about the possibility of trapping the user if canceling a traversal was too easy. The case where we might get out of sync is when multiple frames navigate as part of a traversal. We want to avoid the case where some frames cancel the navigation in their frame, but others allow it to proceed (since giving every frame what it requested would cause some frames to be out of sync with the browser process). Therefore, only the main frame is allowed to cancel the navigation via the navigate event. In order to ensure the main frame is able to cancel the entire traversal, we send the main frame navigation (if any) to the renderer first and wait for its commit to complete before proceeding with any subframe navigations. The main frame is only allowed to cancel a traversal when it is traversing same-document (regardless of whether its subframes traverse same-document or cross-document). We had originally planned on allowing cross-document traversals to be cancelled, too (https://chromium-review.googlesource.com/c/chromium/src/+/3868615), but this proved to have unacceptable performance characteristics, requiring roundtrips to the renderer whenever a navigate event handler was present, even if the navigate event handler had no intention of ever cancelling a traversal. Therefore the sequence during a traversal is now: 1. Calculate which frames to navigate, and invoke Navigator::Navigate() for each. 2. The main frame's NavigationRequest will proceed as normal. 3. If the main frame needs to do a same-document navigation, then: 3a. Any subframe navigations will be deferred until the main frame NavigationRequest either commits or is canceled. 3b. If it cancels, abort the entire traversal. 3c. Resume all deferred subframes. These navigations will all fire a navigate event just before committing, but none of those of those events will be cancelable. As for preventing trapping the user, we only allow canceling the navigation in the main frame if the navigating is programmatic, or if there is a consumable user activation. This ensures that, e.g., pressing the back button once might be canceled by the navigate event, but the second back button press is guaranteed to go through. Traversals via the navigation API or the legacy history API will always be cancelable because they are programmatic. Canceling a traversal consumes HistoryUserActivationState rather than UserActivationState, in order to minimize the potential for collisions with other UserActivationState consumers that are not in the history/navigation space. Bug: 1371580 Change-Id: I0c8c39bec8e21f3ca86389a4343881ebe2bde43e Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/4092862 Reviewed-by: Domenic Denicola <domenic@chromium.org> Commit-Queue: Nate Chapin <japhet@chromium.org> Cr-Commit-Position: refs/heads/main@{#1106877}
The web-platform-tests Project is a cross-browser test suite for the Web-platform stack. Writing tests in a way that allows them to be run in all browsers gives browser projects confidence that they are shipping software that is compatible with other implementations, and that later implementations will be compatible with their implementations. This in turn gives Web authors/developers confidence that they can actually rely on the Web platform to deliver on the promise of working across browsers and devices without needing extra layers of abstraction to paper over the gaps left by specification editors and implementors.
The most important sources of information and activity are:
wpt:matrix.org
matrix channel; includes participants located around the world, but busiest during the European working day.If you'd like clarification about anything, don't hesitate to ask in the chat room or on the mailing list.
Clone or otherwise get https://github.com/web-platform-tests/wpt.
Note: because of the frequent creation and deletion of branches in this repo, it is recommended to “prune” stale branches when fetching updates, i.e. use git pull --prune
(or git fetch -p && git merge
).
See the documentation website and in particular the system setup for running tests locally.
The wpt
command provides a frontend to a variety of tools for working with and running web-platform-tests. Some of the most useful commands are:
wpt serve
- For starting the wpt http serverwpt run
- For running tests in a browserwpt lint
- For running the lint against all testswpt manifest
- For updating or generating a MANIFEST.json
test manifestwpt install
- For installing the latest release of a browser or webdriver server on the local machine.wpt serve-wave
- For starting the wpt http server and the WAVE test runner. For more details on how to use the WAVE test runner see the documentation.On Windows wpt
commands must be prefixed with python
or the path to the python binary (if python
is not in your %PATH%
).
python wpt [command]
Alternatively, you may also use Bash on Ubuntu on Windows in the Windows 10 Anniversary Update build, then access your windows partition from there to launch wpt
commands.
Please make sure git and your text editor do not automatically convert line endings, as it will cause lint errors. For git, please set git config core.autocrlf false
in your working tree.
The master branch is automatically synced to wpt.live and w3c-test.org.
Save the Web, Write Some Tests!
Absolutely everyone is welcome to contribute to test development. No test is too small or too simple, especially if it corresponds to something for which you've noted an interoperability bug in a browser.
The way to contribute is just as usual:
git checkout -b topic
../wpt lint
as described above.If you spot an issue with a test and are not comfortable providing a pull request per above to fix it, please file a new issue. Thank you!