How should WebDriver BiDi expose prerendering activation? #321
Labels
needs-discussion
Issues to be discussed by the working group
Comments
|
Especially complicated on a spec level, is that HTML currently will call "WebDriver BiDi navigation started" (and perhaps failed) synchronously, at the top level of navigate. Whereas checking whether or not we can do a prerendering activation will only be done in parallel. So, if we were to want to do something besides the default WebDriver BiDi navigation started behavior, we'd probably need to move that callback to be in the parallel section too. Maybe that's fine? |
domenic
added a commit
to WICG/nav-speculation
that referenced
this issue
Nov 18, 2022
Closes #203. Notable: * This removes activating prerendering in place of navigational redirects, as that is more complicated to do with the new spec, and wasn't implemented anyway. The absence of this feature is now noted by an XXX box. * This fixes the non-rigorous session history merging, in a nice and elegant way. * This makes it clear that a navigable-level "loading mode" is not enough to properly specify document.prerendering or document.visibilityState. Fixing this is left for the future, with an XXX box containing some notes on how to do so. * The exact intended behavior with WebDriver BiDi is a bit unclear. See w3c/webdriver-bidi#321. What we have here in the meantime is a reasonable approximation.
|
The Browser Testing and Tools Working Group just discussed The full IRC log of that discussion<jgraham> Topic: How should WebDriver BiDi expose prerendering activation?<jgraham> github: https://github.com//issues/321 <orkon> https://wicg.github.io/nav-speculation/prerendering.html <jgraham> orkon: Prerendering is chrome-only feature not implemented by other browsers. Problem is that it will ship in Chrome and it affects how navigations happen in the browser. Changes the lifetime of the browsing context. There is a spec in WICG (see above). Main idea is that one tab can have two active browsing contexts. Link could destroy current context and active prerendered context. We could discuss if this is something we can accomodate in <jgraham> BiDi e.g. allowing prerendering to have hooks into BiDi so they get predicatable results. Could pretend that prerendering doesn't happen at all, but it doesn't work well with e.g. network interception; should it intercept requests in prerender tab. Opinions on how this should work? <jgraham> orkon: Also it's a topic that requires some backgorund reading, so maybe no solution today, but we should have it on our radar, since there might be other similar changes to the lifecycle. <sadym> q+ <jgraham> Sam Sneddon [:gsnedders]: Some of the problems already exist with preloading, even without prerendering. There are already network requests you could intercept at the point that you're preloading. Other browsers do this, but I don't know if webdriver can trigger them. <sadym> q- <jgraham> orkon: Currently changing the viewport is specific to context, but for prerendering it's technically a different viewport but you'd expect to get the same result. <shs96c> q? <shs96c> q+ <jgraham> jgraham: it's hard to know if this violates any invariants that authors might depend on without examining the spec in detail. For example do we get load events without a navigation, or if we get a navigation for the preload do we get a second one for the actual user initiated navigation? <jgraham> ack shs96c <gsnedders> q+ to ask questions about debugging <jgraham> shs96c: I am opposed to magic. I would be tempted to say that the events should be fired as normal as if it was happening in a normal tab. Then we should have a different event to describe the navigable being activated. We expose the underlying internals. Might break some mental models but it's opt-in, so if you're enabling this you should be able to handle it. <sadym> q+ <jgraham> jgraham: I'm worried about clients invariants being broken which users can't fix. <orkon> q+ answer about puppeteer <jgraham> shs96c: Selenium doesn't really maintain state, but maybe other clients do <jgraham> ack Sam Sneddon [:gsnedders] <jgraham> ack next <orkon> q+ <Zakim> gsnedders, you wanted to ask questions about debugging <jgraham> Sam Sneddon [:gsnedders]: How does this interact with the ability to debug browsing contexts? Can you break on exception in preload navigables? <jgraham> orkon: Yes <jgraham> Sam Sneddon [:gsnedders]: SO you can debug these. Presumably at this point it gets shown somewhere. This seems like an argument we should pass the events through to the client. <jgraham> q+ <jgraham> ack next <jgraham> sadym (IRC): To clarify the proposal we should add a new type of browsing context and add a new event when one is replaced with another. <jgraham> shs96c: That seems like a reasonable model <jgraham> ack orkon <shs96c> q+ <sadym> q+ <jgraham> orkon: For puppeteer having some context on the events. Question is about state e.g. enabling interception for a specific top level context it won't be enabled for the background context, so you'll lose events until it's intercepted. So you need to subscribe to everything. <jgraham> shs96c: Like an inheritable thread local in java <shs96c> q- <jgraham> shs96c: Events could flow through to associated contexts <jgraham> ack jgraham <shs96c> jgraham: the spec will be informed by what you can do in CDP. Agree that events should flow through to clients. If this breaks clients, then that's unfortunate. There will need to be flags on these events to let people know that the events are happening on pre-rendered content, and there will need to be a new event that a navigable will switch <shs96c> jgraham: the existing model is limited. For example, if a context forms an associated browsing context, then that would inherit the event subscriptions from the parent context, but that's not how the spec works at the moment. The spec expects global or specific subscription to events. May need to consider inheriting subscriptions, or more flexible models <jgraham> ack sadym (IRC) <jgraham> ack next <orkon> q+ <sadym> Having the current mechanism already supports inheriting, if we consider the pre-rendered context a special kind of child of the main one, all the events subscriptions will be automatically provided, but the client will be able to filter them out by the browsingContextId, which is provided for all the events (the latest should be double checked). <jgraham> ack orkon <shs96c> q+ to respond about inheriting subscriptions <jgraham> orkon: What worries me a bit is that we could inherit events, but that would technically not be spec complaint because we route commands and events to and from specific top level browsing contexts, and the preload model gives up multiple top level browsing contexts. <jgraham> ack shs96c <Zakim> shs96c, you wanted to respond about inheriting subscriptions <jgraham> ack next <jgraham> shs96c: James was right. <jgraham> We might need to model certain things in the spec as inheriting event subscriptions. I think it would also allow nice functionality. e.g. as a tester I set up request rewriting. The page opens an iframe. I want to automatically inherit the request interception for that iframe. <jgraham> jgraham: window.open is a better example <jgraham> orkon: Or service workers |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
In https://github.com/WICG/nav-speculation/ we're working on specifying prerendering. (Latest spec work, integrated with the recent changes to HTML's navigation algorithm, at WICG/nav-speculation#207 .)
The tricky thing about prerendering is there are two "navigation"-type events:
On the spec level, the latter is done by hooking into the navigate algorithm, and instead of doing most of the normal stuff, instead activating.
HTML's navigate algorithm currently has a variety of WebDriver BiDi callbacks based on a given navigation ID. Should we have any for prerendering activation?
The text was updated successfully, but these errors were encountered: