Interception of created navigables

[OrKoN]

Many WebDriver BiDi methods allow configuring the browser behavior globally or per existing navigable. For example, network.addIntercept can be used either per navigable(s) or apply globally. Similarly, event subscriptions can be done globally or per navigable. The important requirement for calling these methods for a navigable is that the navigable has to exist.

There is another use case that is currently not covered: how to configure newly created navigables? For example, if you want to subscribe to a subset of events depending on the navigable parameter, there is no way to do it in a race-free way without reloading the newly created navigable. Another example could be network interception and event logging: there could be many navigables in a browser that you do not want to intercept requests in, and dynamically created navigables that you do want to set up interception in.

We could extend the navigable creation algorithm with an ability to pause loading of a navigable, notify the client about the navigable and allow the client to resume loading once the commands configuring the behavior of the newly created navigable have been sent. Ideally, that should extend to worker realms since many workers might not be interesting for interception.

cc @sadym-chromium

[OrKoN]

At least a couple of feedback items from Playwright in #769 / #775 could be solved by this feature. cc @sadym-chromium

[whimboo]

I've added that issue to the TPAC agenda for discussion.

[css-meeting-bot]

The Browser Testing and Tools Working Group just discussed Interception of created navigables.

The full IRC log of that discussion

<AutomatedTester> Topic: Interception of created navigables
<jgraham> q+
<sadym> q+
<AutomatedTester> github: Interception of created navigables
<jgraham> github: https://github.com//issues/776
<jgraham> github: https://github.com//issues/756
<dmurph> We need to test behavior that involves clicking a link which opens a new frame / navigable. And then do test steps in that frame. Is this supported today? If not - that issue sounded like it was to add that support
<AutomatedTester> scribe+
<AutomatedTester> q?
<jgraham> ack next
<Zakim> dmurph, you wanted to ask about github issue: https://github.com//issues/756
<AutomatedTester> ack jgraham
<AutomatedTester> jgraham: what is possible in general that when a navigable is created you get an event with an id and you can send commands to that id
<AutomatedTester> ... the issue here is about automatically config navigables
<AutomatedTester> ... [explains how the viewport info could be inherited but isn't currently there]
<AutomatedTester> ack sadym
<AutomatedTester> sadym: from understanding is "install web app, click links and make sure the app keeps the new windows"
<AutomatedTester> dmurph: that sounds correct
<AutomatedTester> jgraham: in bidi there is not concept of an installed app. if you need to add more details you will need to extend bidi spec
<AutomatedTester> dmurph: sounds like we can get started here and get going
<AutomatedTester> q?
<AutomatedTester> jgraham: just to be clear, we haven't discussed this issue. The issue as part of this about how to make sure that config items are inherited across navigables as they are created.

[css-meeting-bot]

The Browser Testing and Tools Working Group just discussed Interception of created navigables.

The full IRC log of that discussion

<AutomatedTester> topic: Interception of created navigables
<AutomatedTester> github: https://github.com//issues/756
<simonstewart> sadym: there are some use cases when users want to prepare subscriptions for events after the browsing context is created, but before anything has happened
<simonstewart> sadym: analogous connecting to a debugger
<simonstewart> sadym: we can implement this with global subscriptions, but that seems suboptimal. I'm not sure if there are scenarios that can't be implemented this way
<simonstewart> jgraham: I agree that this is a use case we need to address.
<simonstewart> jgraham: particularly for something like `window.open`, you'd want the same subscriptions to be taken to the new window, but in general you'd want this if a new context is created.
<AutomatedTester> q+
<simonstewart> jgraham: I'm not sure if there's a way to pause that creation
<simonstewart> q-
<simonstewart> jgraham: I don't know if the debugger in Firefox has to deal with this, since it only deals with one window at a time.
<sadym> q+
<simonstewart> jgraham: One can imagine other ways of handling this, but it's hard to know if you can pause things
<simonstewart> jgraham: such as an event before a navigable is created, and then respond with a list of subscriptions to add
<simonstewart> ack next
<AutomatedTester> ack AutomatedTester
<simonstewart> AutomatedTester: we know that some people want to be able to have sessions per tab because of the way that they run their tests. If we do this inheritance model, how would that work for that use case?
<simonstewart> jgraham: there is a little bit of overlap with subscribing to stuff for specific user contexts. That is, if a tab is opened in this specific user context, then <scribe gets lost attempting to listen and type at the same time>
<simonstewart> jgraham: if you could configure events at the user context level, that might solve a bunch of issues
<AutomatedTester> ack sadym
<simonstewart> sadym: another use case is setting the viewport when the browsing context is opened
<simonstewart> sadym: it's not event related and it's not solvable currently
<simonstewart> jgraham: yesterday, we discussed that we can't set some of the emulations at the top-level anyway because we think it might be process-level state.
<simonstewart> jgraham: a possibility is that we'd only allow setting those things for user contexts
<simonstewart> jgraham: and if you could also do "set viewport", but it applied to a user context and not a global, maybe that would be a declarative solution to a large subset of these issues
<simonstewart> jgraham: we'd have global, user, browser contexts in that order
<simonstewart> sadym: does that cover all use cases?
<simonstewart> jgraham: it's definitely less flexible than being able to pause creation
<simonstewart> Action: Julian to see if gecko can pause creation of new navigables
<simonstewart> RRSAgent, create minutes
<RRSAgent> I have made the request to generate https://www.w3.org/2024/09/27-webdriver-minutes.html simonstewart
<simonstewart> sadym: but we'd not be able to do what we can with CDP
<simonstewart> sadym: but you're saying we can set things at the browser context or user context?
<simonstewart> jgraham: yes
<AutomatedTester> q?
<simonstewart> jgraham: I suspect that most test clients will want to be able to say something like "I'm running some tests, and I'd like to have all windows emulate the same conditions" This would allow this to happen
<simonstewart> gsnedders: I don't know if webkit can pause the creation of new navigables
<simonstewart> sadym: I wonder how firefox with cdp worked?
<simonstewart> jgraham: I'm not sure it worked, but if it did, then this suggests it's possible
<simonstewart> jgraham: it does sound complicated, and we should investigate properly
<AutomatedTester> q?

[whimboo]

Action: Julian to see if gecko can pause creation of new navigables

I wonder if document.blockParsing() could be helpful here. But I'm not sure if that is just for parsing scripts, or if we could stop the full parser.

@juliandescottes do you know?

[whimboo]

We had some internal discussions today, and one option that emerged is allowing customization of specific user contexts, as mentioned in this issue. This approach would still require opening an additional tab but seems much cleaner than returning early from browsingContext.createContext and then resuming.

@OrKoN would that be an option, or won't that cover all specific features wanted for that request?

[OrKoN]

I think it would not work for some existing Puppeteer's APIs, e.g., the request interception in Puppeteer is per top-level browsing context and would not be easy to apply to the user context.

I think instead of interception (given the complexity and the requirement for message roundtrips) we could introduce a parameter to indicate that a particular configuration (emulation or event subscription) needs to be inherited by the contexts opened from the current one. I think this Playwright feedback item would be addressed by either interception or inheritance of certain configuration options:

Provide a way to configure the viewport before a popup or new tab starts loading content. Currently, the browsingContext.SetViewport command can only be sent to an existing page, and there is no way to pause the load of a new page (e.g., opened via ctrl+click or a popup); these pages always load with the default viewport first.

(microsoft/playwright#32577)

[OrKoN]

So if we do not want to go with pausing the loading, we could allow inheriting configurations on the per-command basis, for example, #803