[WPT] Introduce RemoteContext.execute_script() and add basic BFCache tests + helpers

[chromium-wpt-export-bot]

This PR adds RemoteContext.execute_script() and its documentation
in /common/dispatcher/.
This is based on with execute_script()-related parts of RFCs 88/89/91:

• RFC 88: [testdriver] Extend the mechanisms for giving browsing contexts ids. rfcs#88
• RFC 89: [testdriver] Add an execute_script function to testdriver. rfcs#89
• RFC 91: [testdriver] RemoteContext object rfcs#91

and addresses comments:

• RFC 86: fetch_tests_from_prefixed_local_storage rfcs#86 (comment)
• [WPT] Introduce RemoteContext.execute_script() and add basic BFCache tests + helpers #28950 (comment)

plus additional clarifications around navigation,
minus testdriver integration (so this PR is implemented using
send()/receive() in /common/dispatcher/),
minus web-platform-tests/rfcs#90
(so this PR leaves send()/receive() as-is).

This PR also adds back-forward cache WPTs (basic event firing tests),
as well as BFCache-specific helpers, based on
RemoteContext.execute_script().

Design doc:
https://docs.google.com/document/d/1p3G-qNYMTHf5LU9hykaXcYtJ0k3wYOwcdVKGeps6EkU/edit?usp=sharing

Bug: 1107415
Change-Id: I034f9f5376dc3f9f32ca0b936dbd06e458c9160b
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/2885636
Reviewed-by: Rakina Zata Amni <[email protected]>
Reviewed-by: Arthur Sonzogni <[email protected]>
Commit-Queue: Hiroshige Hayashizaki <[email protected]>
Cr-Commit-Position: refs/heads/main@{#927566}

[wpt-pr-bot]

The review process for this patch is being conducted in the Chromium project.

[hiroshige-g]

Hi people around #16359,

This PR sketches how BFCache WPTs can be written, using a basic test on event firing.

As for Fergal's proposal at #16359 (comment):
My PR asserts PRECONDITION_FAILED if a certain page is not in BFCache unexpectedly, but by observing JavaScript behavior like pageshow events, rather than isPreviousPageInBFCache (so the implementation of isPreviousPageInBFCache is not included).
This is to unblock other WPTs that can be written in a similar fashion early, so I'm planning to land this PR and then create a bunch of WPT PRs using the testing scheme introduced in this PR, in pararell to isPreviousPageInBFCache-related things.
isPreviousPageInBFCache might be helpful to provide direct checks on BFCache states and for scenarios that don't fit within this scheme, e.g. where we can't back navigate to observe pageshow events, but I think pageshow-based detection is sufficient for the first commit for this kind of simple scenarios. Changes to switch to isPreviousPageInBFCache later will be small anyway.

I put some other details in the description and comments within the JS files.

WDYT? Suggestions are welcome.

cc/ @jugglinmike @gsnedders @annevk @zcorpan @fergald @smaug---- @cdumez @rakina @domenic @jakearchibald @foolip who might have opinions.

[foolip]

@past are you able to help out reviewing this? I'll also take a look, but it's an important new bit of test infrastructure, and it'd be good to have more eyes on it.

[foolip]

Just a thought without having reviewed the code yet...

the WPT test infrastructure doesn't support navigating the main test Document

Is this limitation a big problem, are there ways of supporting that you've considered that seem too intrusive or too much work? There are quite a lot of tests that need this I think and they end up opening an iframe. Do you think the iframe trick will work for BFCache too, or won't this be a problem?

[smaug----]

Opening an iframe for bfcache tests? bfcache is for top level pages only (at least in certain implementation, since supporting iframes is tricky and probably not that useful).
Opening a new window should work, assuming there is some commonly supported API which can be used for communication between noopener window and the main test document. The tests seems to be relying on localStorage.
(For Gecko we've used BroadcastChannel, since the page isn't evicted from bfcache if there isn't communication in the channel while it is in bfcache)

[fergald]

We can't open a new window because we cannot cache a page that has another window in the same browsing context group. Basically if something else can script it or send messages to it then it cannot enter the cache. Local storage provides a way to communicate and still be cacheable. This is definitely not ideal and would not be necessary if we had something like IsPreviousPageInBfcache().

[smaug----]

Yes you can cache new windows, if they are opened using noopener :)

[hiroshige-g]

Is this limitation a big problem, are there ways of supporting that you've considered that seem too intrusive or too much work?

The combination of top-level cross-site navigations, isolated windows, BFCache eligibility (i.e. Windows opened by iframe and window.open() without noopener aren't eligible at least in Chromium), and efforts to prevent cross-origin communications for security/privacy reasons complicates the design like where the test logic should be placed and what communication channels can be used.

Alternatives considered for window.open() with noopener:

• iframe and window.open() without noopener: not BFCache-eligible at least in Chromium
• Support navigating main test Documents: not sure, but probably needs more work (updating test runners for all browsers) and more design.

Alternatives considered for localStorage:

• Fetch API + server-side stash: A page with open fetch requests is not BFCache-eligible in Chromium, so a little more coordination is needed to ensure the fetch requests for accessing stash are closed before navigation.
• BroadcastChannel: A page with open BroadcastChannels is not BFCache-eligible in Chromium. BroadcastChannel is not supported in Safari.

Anyway these things might be just workarounds and not perfect, and I'm also thinking of more generalized/cleaner framework for navigation-related tests. Maybe test runner/WebDriver APIs? Maybe a test is controlled from outside, like from main test Document or even outside HTML? Maybe the test state is in persistent storage (e.g. stash)? But I haven't come up with concrete ideas yet.

[foolip]

I misspoke in my previous question, I wanted to ask about window.open() which is used a fair bit, not iframes. But it sounds like opening new windows also doesn't really help.

Anyway these things might be just workarounds and not perfect, and I'm also thinking of more generalized/cleaner framework for navigation-related tests. Maybe test runner/WebDriver APIs? Maybe a test is controlled from outside, like from main test Document or even outside HTML? Maybe the test state is in persistent storage (e.g. stash)? But I haven't come up with concrete ideas yet.

I can see two things that might be helpful here:

• testdriver.js APIs that make it possible for a page to know if it's BFCache-eligible and the BFCache status of other pages in history.
• A new class of tests that drive the browser from the outside, much more like WebDriver tests. These would probably be written in Python. Such tests could open multiple browser tabs/windows/instances and shuffle information between them without requiring the stash or similar mechanism.

[hiroshige-g]

Status:
I drafted a RFC for fetch_tests_from_prefixed_local_storage() at web-platform-tests/rfcs#86.
I got a comment about COEP's executor-based style (web-platform-tests/rfcs#86 (comment)), and I found it seems to work better (probably), especially for SW-related tests.
I'm rewriting the basic event test (this PR) and another SW-related test using the COEP style, and will upload a draft PR.

[hiroshige-g]

OK, I switched this PR (and my other drafts) to the COEP's executor framework, and thus dropped the changes to testharness.js and /common/ and the RFC.

I also removed visibilitychange events from the test, because document.visibilityState at the time of window load event is flaky on Safari (WPT draft: #29600). I might add tests for visibilitychange events later, but anyway I'd like to land the helpers first to unblock other tests.

Ready for code review again. WDYT?

[jgraham]

I haven't reviewed this in detail, but I'm happy with the general shape of the execute_script model; it's very like where I've landed in RFC web-platform-tests/rfcs#98 and I think it will be possible to consolidate on a single implementation in the future without too mcuh difficulty.

[ArthurSonzogni]

LGTM on my side.

[hiroshige-g]

Any more comments or suggestions?
I'd like to land this PR around the end of this week, after I wait for a while for more comments and address them if any.

[hiroshige-g]

The underlying Chromium CL has landed.

The failures on stability bots are existing flakiness in COOP tests and thus are not related to this PR.

[past]

Thanks Hiroshige!