search

w3c / webdriver-bidi

Bidirectional WebDriver protocol for browser automation
https://w3c.github.io/webdriver-bidi/
363 stars 40 forks source link

Support user contexts #570

Closed OrKoN closed 8 months ago

OrKoN commented 12 months ago

User Contexts allow basic isolation of the web content state and parallelization of test runs without paying the costs of launching a fresh/multiple browser processes. In this proposal, there is no session created for the user context: multiple user contexts are managed by the same session. The advantage is that the same session can create a fresh state for its operations. In practical terms, we want to have something that would allow us to implement https://pptr.dev/api/puppeteer.browsercontext/#example In Chrome, that corresponds to an incognito window (but you can have multiple for automation).

Issue https://github.com/w3c/webdriver-bidi/issues/289

Related links:

Open questions/TODOs:

Preview | Diff

OrKoN commented 9 months ago

Looks like I have messed up the branch a bit. Please do not review changes for now.

OrKoN commented 9 months ago

I have recovered lost changes and the PR is now ready for review.

css-meeting-bot commented 8 months ago

The Browser Testing and Tools Working Group just discussed Support user contexts.

The full IRC log of that discussion <jgraham> Topic: Support user contexts
<jgraham> github: https://github.com/w3c/webdriver-bidi/pull/570
<jgraham> MaksimSadym: Alex is out. AFAIK the main concern now is whether we should add the command to get the current user contexts.
<jrandolf> q+
<jgraham> jgraham: I think this was related to a deeper discussion about having ids that are the same for all sessions vs ids that are different between different sessions, although I'm not sure how much dropping the get command helps. For nodes we currently require per-session ids, but as the spec is written contexts get the same id in all sessions. So we should probably have policy here. But if we don't need
<jgraham> the get command for the initial use cases of user contexts it's also OK to drop for now. But we'll need it later.
<jgraham> ack jrandolf
<jgraham> jrandolf: We were internally discussing how to get to the formal model you want in the PR. The discussion about ids reflects what the formal model is. From our understanding it seems like you want a formalised model that's based on sets, but when you try to implement such a model it becomes implementaion specific. So we want to understand how we should word this in the framework of sets, whilst also
<jgraham> including the fact that it's implementation specific.
<jrandolf> jgraham: If the model doesn't work, than we can move on. The model in my mind was that user contexts live on the browser so therefore they have some associated set of contexts. We can do this only in WebDriver BiDi since this is only visible in WebDriver BiDi.
<jrandolf> 1. How do we model the IDs between user contexts and browsing contexts.
<jrandolf> 2. Should user contexts be named or have automatically generated ID.
<jrandolf> q+
<jgraham> jgraham: I will write this up in the PR. I don't think it necessarily has to block, but I'm concerned at too many oeprations being "implemenation defined"
<jgraham> ack next
<jgraham> jrandolf: Could we think about this as a setter/getter e.g. every browser has a set of user contexts that has an implementation defined way of adding and removing contexts from the set.
<jgraham> jgraham: I'm not sure which part we want to call out as implemenation defined. We have a set of user contexts. All top level trversables have an associated user context which is one of the ones in the set. The implementation is free to change the contents of the set, as long as the invariants are maintained.
<jgraham> jrandolf: How do we model the side effects of adding to the set of user contexts? Or do we?
<jgraham> jgraham: I'm not sure, maybe you could write up in the PR specific cases you're worried about. It seems like there should be precedent with e.g. navigables.
<jgraham> RRSAgent: make minutes
<RRSAgent> I have made the request to generate https://www.w3.org/2024/01/10-webdriver-minutes.html jgraham
<jgraham> zakim, bye
<Zakim> leaving. As of this point the attendees have been jgraham, MaksimSadym, AutomatedTester, jdescottes, jrandolf, lightning00blade, whimboo, sasha, cb, JimEvans
<jgraham> RRSAgent, bye
<RRSAgent> I see no action items
juliandescottes commented 8 months ago

As mentioned on matrix, Firefox' containers persist after closing the browser. If the Chrome equivalent is ephemeral, maybe the spec should be clear about the lifecycle of the contexts created by a WebDriver BiDi session? Eg explicitly say that they will be destroyed at the end of the session, or when closing the browser?