| commit | 92cd57ebc8bf216199fa9a8a9225e978a2197371 | [log] [tgz] |
|---|---|---|
| author | Liam Brady <lbrady@google.com> | Thu Mar 07 22:25:49 2024 |
| committer | Blink WPT Bot <blink-w3c-test-autoroller@chromium.org> | Thu Mar 07 22:44:35 2024 |
| tree | 0342800c4223c695e4084cf8766ac018bae0c6c3 | |
| parent | 635a87312b0700d82f1f3c4fe0c82f5f2f165a0f [diff] |
Clear user activation on cross-site navigations. When full site isolation is disabled, renderer processes and RenderFrameHosts are re-used when performing cross-site navigations. This includes user activation state, and, more specifically, the sticky `has_been_active_` bit in `UserActivationState`. Currently, the `UserActivationState` on the renderer-side is reset only if the navigation's associated frame is a main frame. That means that if an iframe navigates to a cross-site page, its sticky user activation state will be the leftover state from the previous page. So, if a user interacted with the previous page in any capacity, the newly loaded page will think it has received a user gesture, essentially using an unintentional cache of the user activation state. This becomes an issue when dealing with our framebusting interventions. We only allow an iframe to do a top-level navigation if it received a user gesture. However, if an iframe's previous document received a user activation, or worse, if the iframe was not navigated to anything and got a user activation because its embedder was interacted with, this allows the current document to circumvent our framebusting interventions. The latter happens because of same-origin descendant activation behavior. See: https://source.chromium.org/chromium/chromium/src/+/main:content/browser/renderer_host/frame_tree_node.cc;l=766-778;drc=30753b1135fa271a3b45bbdbfef6567e46733a7f;bpv=1;bpt=1 Note that this problem does not exist if site isolation is enabled (which is by default on desktop platforms), since a cross-site navigation will create a whole new process with a fresh `UserActivationState`. To fix this, this CL clears the user activation state on cross-site subframe navigations in the renderer (user activation is already cleared for main frames). To ensure that same-site navigations persist user state even if a cross-origin or same-origin navigation results in a new process or RenderFrameHost being created, this CL also explicitly transfers sticky user activation state for all same-site cross-RenderFrameHost navigations. This takes place in the browser, and the resulting bit to determine if a frame should have sticky user activation is passed to the renderer. The ultimate end goal is to unconditionally clear the user activation state for all cross-document navigations. That unfortunately is not possible today as there are entrenched use cases that rely on sticky user activation state being cached for same-site navigations. See: https://crbug.com/40228985. This CL also fixes the aforementioned regression when enabling the RenderDocument feature, since this CL will now preserve the sticky user activation state regardless of what process/RenderFrameHost/RenderDocument state the navigation results in. This CL adds some tests to the no-auto-wpt-origin-isolation test suite, which requires some additional description: * These tests are running on all platforms because site isolation behavior may differ per platform * All of the tests in the-iframe-element are being added because it would be useful to understand their behavior in all expected process configurations * The total time taken for this test suite on linux-rel showed a total time percentage of <0.3% Bug: 41493458 Change-Id: Ibec11437fcd03470571e04a4e0dfaadffddf6c03 Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/5269464 Reviewed-by: Mustaq Ahmed <mustaq@chromium.org> Reviewed-by: Charlie Reis <creis@chromium.org> Reviewed-by: Jeremy Roman <jbroman@chromium.org> Reviewed-by: Robert Flack <flackr@chromium.org> Reviewed-by: Andrew Verge <averge@chromium.org> Commit-Queue: Liam Brady <lbrady@google.com> Reviewed-by: Alex Moshchuk <alexmos@chromium.org> Reviewed-by: danakj <danakj@chromium.org> Cr-Commit-Position: refs/heads/main@{#1269856}
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!