Open sadym-chromium opened 1 year ago
Commands for this could be browsingContext.setUserAgent
and browsingContext.getUserAgent
. Passing null
as user agent should reset the formerly set custom user agent.
Actually retrieving the current user agent could be done by script evaluation and returning navigation.userAgent
. So we probably only need a way to set a custom user agent.
Isn't this a duplicate of https://github.com/w3c/webdriver-bidi/issues/446? cc @OrKoN
No, it is not: https://github.com/w3c/webdriver-bidi/issues/446 is about getting the original non-emulated user agent from a browser binary without a need to have browsing contexts.
I wanted to bring up User-Agent Client Hints. Although it’s a separate feature, it’s somewhat related to User-Agent string emulation, and as a user you’d probably want to emulate both the User-Agent string + the Client Hints accordingly (since otherwise it’s trivial for the target page to detect emulation).
Our options are:
A. include Client Hints support as part of this API B. provide a separate API for Client Hints C. support User-Agent emulation without Client Hints emulation
An example of A would be CDP’s Emulation.setUserAgentOverride
which accepts an optional userAgentMetadata
param that configures the Client Hints.
The Browser Testing and Tools Working Group just discussed Emulation features - User agent override
.
Let's start with C).
From the IRC log above:
orkon: Let's drop CH as that is out of scope. UA changes can be good for browsers vendors but not for the average tester
It seems that we do not want to pursue client hints. @OrKoN could you confirm this?
I am intending to add this command as part of the "browsingContext" module (e.g. instead of a new"emulation" module).
Within the WebdriverIO framework we are using script.addPreloadScript
to emulate this Web API, e.g.
await this.scriptAddPreloadScript({
functionDeclaration: /*js*/`() => {
Object.defineProperty(navigator, 'userAgent', {
value: ${JSON.stringify(options)}
})
}`
})
Is there any advantage to have this handled through the protocol?
Is there any advantage to have this handled through the protocol?
I don't know, hopefully someone else can answer it. I can only imagine that if it was that easy then it would have been brought up before during the WG meeting.
Within the WebdriverIO framework we are using
script.addPreloadScript
to emulate this Web API, e.g.await this.scriptAddPreloadScript({ functionDeclaration: /*js*/`() => { Object.defineProperty(navigator, 'userAgent', { value: ${JSON.stringify(options)} }) }` })
Is there any advantage to have this handled through the protocol?
I believe this would not be used for outgoing network requests. While it's possible to solve it via request interception, it is often easier to change it at once.
@thiagowfx Client Hints are completely out of scope for the WebDriver BiDi spec. I recall there were also some concerns from Selenium about adding this feature. Perhaps, we need to discuss again given that we have a draft. In Puppeteer, the feature would allow supporting https://pptr.dev/api/puppeteer.page.setuseragent/.
There are two options to move forward with this:
1) Implement client side using preload scripts + request interception
Pros: Does not require spec changes. Cons: Request interception introduces round-trips for each request reducing performance if the use case involves only changing the user agent. Complexity moves to the client.
2) Implement browsingContext.setUserAgent as part of the protocol.
Pros: No performance degradation; simple client implementation.
Cons: Requires extending the spec with something that already can be done by other (although less efficient) means.
The Browser Testing and Tools Working Group just discussed Support emulation of the User-Agent
.
Closed in favor of initially supporting this feature client-side using preload scripts and request interception. Can revisit if more clients require that.
From the Playwright team there was also the request to add support for emulating the user agent per user context. Maybe this should be more a general issue given that it affects other emulation features and events as well?
I think it would be great to file a separate issue to discuss (generic) per user context configuration for all commands, although we would probably need to specify it per command anyway. I will update the description to mention these details for the user agent emulation.
I think it would be great to file a separate issue to discuss (generic) per user context configuration for all commands
I filed https://github.com/w3c/webdriver-bidi/issues/775 for that wanted discussion.
it should be possible to set a custom user agent:
1) per browsing context with sub-contexts 2) per user context (requires decision from https://github.com/w3c/webdriver-bidi/issues/775)
The emulation should affect the output of Web APIs observable to the page as well as the network headers for outgoing requests.