RFC 88: [testdriver] Extend the mechanisms for giving browsing contexts ids.

[jgraham]

No description provided.

[jgraham]

There is maybe another option here. Instead of giving each context an id as part of the URL we instead rely on the fact the test window is special, and let the remote window message the test with its id. So something like:

test.html

win.open("child.html", null, "noopener");
let remote_id = await test_driver.recv();
let ctx = test_driver.RemoteContext(remote_id);
ctx.delete_all_cookies();

child.html

test_driver.test_window.send(test_driver.get_context_id())

So there are some problems with this; notably that on a page with multiple subtests you need to make sure you end up gettting the context id for the context that you created. But the advantage is that it avoids the need to expose the uuids directly (and we can imagine an API where they're fully hidden), and that by forcing the child context to signal when its ready, we avoid a race between window.open() and trying to access the context. Obviously in this case the messaging would be via some non-WebDriver channel c.f. #90.

[gsnedders]

I have some concerns about exposing the property, especially given it's only really needed for WebDriver-based implementations (and, as noted, WebDriver BiDi is unlikely to need it).

That said, I guess we do need to expose some opaque ID to the page for the sake of being able to write testdriver actions that occur on a new window… I do worry that making it part of the URL will lead to multiple IDs longer term (or with non-WebDriver implies today).

So there are some problems with this; notably that on a page with multiple subtests you need to make sure you end up gettting the context id for the context that you created.

Could we have something like: test_driver.open_new_window(url='about:blank'), which returns a Promise which fulfills to a ctx?

[jgraham]

So there are some problems with this; notably that on a page with multiple subtests you need to make sure you end up gettting the context id for the context that you created.

Could we have something like: test_driver.open_new_window(url='about:blank'), which returns a Promise which fulfills to a ctx?

My worry about this is we need to come up with testdriver mechanisms to handle all possible context creation scenarios. For example, what if we want to do the same kind of thing, but with an iframe? Also we want to allow setting different options on the window (e.g. noopnener), so the implementation can't use a WebDriver primitive, it would have to run js script. Then we're back in the situation where we don't know which context is the one we just created on the WebDriver side.

Fundamentally the difficulty here is the need to have a shared identifier for browsing contexts which is accessible both to JS code and to WebDriver/wptrunner. The JS code needs access so that we can specify which context we want to send commands and messages to, and the wptrunner side needs to know which WebDriver window (or frame) we need to switch to when running a specific command. I very much agree that making the user generate these ids explicitly and put them into the URL is not optimal, and in a few years WebDriver-BiDi might be well enough supported to make a different approach possible. So I agree that in the long term we run the risk of having some unfortunate legacy if we go with explicit identifiers. But if there's a clever way to avoid needing them without waiting for BiDi, I haven't yet worked out what it is.

[hiroshige-g]

While the RFC title says "browsing contexts ids", is this / should this be actually IDs for Windows (and other realms)?
When we navigate from URL A to URL B (within the same browsing context), we need to, and the draft PR web-platform-tests/wpt#29803 does, distinguish these two.

[jgraham]

Yeah, it's a bit ambiguous, or rather you can do both. In the PR, if you have an browsing context container with a uuid in the src attribute, that can be used as the uuid irespective of the current url of the loaded document. But if you have a noopener window you'd need to pass the uuid into subsequent URLs loaded in order to keep the same one, or otherwise generate a new one to get a different id for each document loaded. Which you want depends on what you're trying to achieve.

[hiroshige-g]

COEP tests contain script injection into workers/service workers (executor_js_path and sw_executor_js_path in /wpt/html/cross-origin-embedder-policy/credentialless/resources/common.js). I don't know the details though. FYI @ArthurSonzogni

[foolip]

By the 2-years-in-stable policy I've suggested elsewhere, we could use URLSearchParams:
https://developer.mozilla.org/en-US/docs/Web/API/URLSearchParams/URLSearchParams#browser_compatibility

[foolip]

Did you intend to leave the TODO here?

[jgraham]

I propose withdrawing this. #98 has an alternative with only the uuid URL parameter part of this change. That seems like the most valuable part of the API surface.