Ability to get the user agent

[OrKoN]

In CDP, Browser.getVersion returns userAgent fields that are used by Puppeteer for https://pptr.dev/api/puppeteer.browser.useragent which allows getting the user agent without a need for any browsing contexts to exist.

Does it make sense to add it to WebDriver BiDi? (perhaps, as the result of session.new command)

[christian-bromann]

Aren't these information already available? The exact browser version is returned by e.g. Chromedriver when a session is initiated. The user agent can be retrieved by an evaluate command.

[OrKoN]

@christian-bromann I suspect the evaluated command would return the emulated user agent and requires a page (browsingContext) to be working? Thanks for the pointer about the version, overlooked that!

[christian-bromann]

I suspect the evaluated command would return the emulated user agent and requires a page (browsingContext) to be working?

I am not entirely sure about the differences about an emulated and actual user agent, nor how this impacts the use case you are going for.

[OrKoN]

The difference is that Browser.getVersion returns the user agent that is computed by the browser by default or configured via command line arguments and evaluation of a script might return the user agent that is emulated https://chromedevtools.github.io/devtools-protocol/tot/Emulation/#method-setUserAgentOverride (Emulation of the user agent is probably smth that will have to be discussed separately.).

P.S. I have updated the issue based on the info you provided, thanks!

[whimboo]

What about returning the original user agent as part of the new session capabilities? Could that be an option? It would have to be retrieved only once anyway given that it is static.

[OrKoN]

That would work!

[whimboo]

@jgraham when remote ends return the user agent via the capabilities, does it require a spec change? Probably yes given that it will not be a vendor specific capability.

[css-meeting-bot]

The Browser Testing and Tools Working Group just discussed Emulation features - Get the unmodified (original) user agent.

The full IRC log of that discussion

<AutomatedTester> topic: Emulation features - Get the unmodified (original) user agent
<AutomatedTester> github: https://github.com//issues/446
<shs96c> q+
<AutomatedTester> orkon: this is related to the previous issue. It can be useful to get the UA when a session is started that we return it
<AutomatedTester> ack next
<AutomatedTester> ... are there some concerns about doing this?
<AutomatedTester> ack next
<jgraham> q+
<AutomatedTester> shs96c: jgraham pointed out that on some urls that it changes the UA but having the default UA returned can be useful
<AutomatedTester> ack next
<gsnedders> q+
<AutomatedTester> jgraham: I think in general to have getters for any setters we have
<AutomatedTester> ... so the case where the browser changes things under from you then we should return it if requested
<AutomatedTester> ... for returning it in new session caps that makes sense
<AutomatedTester> ... if there is a use for it i am happy to have it in the spec
<AutomatedTester> ack next
<AutomatedTester> Sam Sneddon [:gsnedders]: I wanted to point out there are cases where the UA string can change depending on the setting. e.g. on mobile requesting the desktop version of the browser
<AutomatedTester> ... I broadly agree with jgraham that we should have getters for setters
<gsnedders> s/desktop version of the browser/desktop version of the site/
<AutomatedTester> jgraham: I think we should return things that people could set or if the rbowser can change underneath them
<AutomatedTester> ... I dont think its bad to return it in new session
<AutomatedTester> q?
<jgraham> RRSAgent: make minutes
<RRSAgent> I have made the request to generate https://www.w3.org/2023/09/15-webdriver-minutes.html jgraham

[css-meeting-bot]

The Browser Testing and Tools Working Group just discussed Ability to get the default user agent (via capabilities).

The full IRC log of that discussion

<AutomatedTester> topic: Ability to get the default user agent (via capabilities)
<AutomatedTester> github: https://github.com//issues/446
<AutomatedTester> orkon: Let me introduce it. In Puppeteer we need an API to know what browser we are talking to
<AutomatedTester> ... I am wondering if we can do this via a capability?
<AutomatedTester> q?
<AutomatedTester> q+
<AutomatedTester> automatedtester: Computed capabilities can be fine especially we do this when looking at the differences between devices. The question here is why isn't �browserName� good enough here?
<AutomatedTester> orkon: the browsername is fine but there ar e parts of the UA that are useful to our users and we want to be able to return that
<AutomatedTester> Sam Sneddon [:gsnedders]: I'm not against allowing people to match on UA
<AutomatedTester> ... having to start the browser to figure out if we can match is painful
<AutomatedTester> ... in the PR my question was around if you pass in alwaysMatch that the UA and return something else that would be weird at a protocol level
<AutomatedTester> ... and I don't think it would block the PR but we need to make sure we have a matrix test to show what we want.
<AutomatedTester> q?
<AutomatedTester> ack next
<AutomatedTester> q?
<whimboo> q+
<gsnedders> s/we need to make sure we have a matrix test to show what we want./as the discussion on Matrix showed, we need to have some discussion about how we generally want to deal with output-only capabilities when passed in as an input./
<AutomatedTester> orkon: I think that I will need to have a look and improve the spec here on what we do if someone passes in a capability that is an output only capability that can never be matched
<AutomatedTester> ack next
<AutomatedTester> whimboo: it would make sense tohave a new issue filed around this and have a meaningful discussion around this
<AutomatedTester> ... as for matching we are already have ways to do matching before the browser is up as much as possible but we need a way know. this
<AutomatedTester> ... e.g. setWindowRect capability is missing for how we handle it
<AutomatedTester> action: Raise an issue around capability matching on output only capabilities
<MaksimSadym> not a problem