Should the "New Session" command return default values for capabilities that have not specified?

[whimboo]

Follow-up from #1812.

While implementing the user prompt handler changes for WebDriver BiDi for the beforeunload user prompt in Firefox I noticed that Firefox and Chrome return both the default value for unhandledPromptBehavior when the capability has not been specified for the New Session command. Safari has a different handling here and doesn't return it.

This question most likely also applies to other capabilities like setWindowRect and others. Some capabilities we use for matching and others not. So maybe we should only do that for those that are utilized for capability matching?

If we agree that we should return the default value, the proposal for a fix could look like 6294a95.

CC @jgraham, @OrKoN, @sadym-chromium, @gsnedders, @AutomatedTester, @shs96c, @jimevans.

[jgraham]

Conceptually it makes sense to always return capabilities that might not just reflect the input value. From that point of view I don't think returning unhandledPromptBehavior makes a lot of sense.

But at this point I'm more worried about compatibility, and it seems more compatible to return the value than not. Therefore I wonder if we should adopt the model where all known capabilities are always returned, even if the value just matches the input?

[sadym-chromium]

Returning all the capabilities were used sounds reasonable, even though it creates a bit more traffic.

[css-meeting-bot]

The Browser Testing and Tools Working Group just discussed Should the "New Session" command return default values for capabilities that have not been specified?.

The full IRC log of that discussion

<jgraham> Topic: Should the "New Session" command return default values for capabilities that have not been specified?
<jgraham> GitHub: https://github.com//issues/1813
<orkon> jgraham: should we return the defaults for capabilities that are not specified? at the moment in classic webdriver the spec says you return certain capabilities always, such as browser name, or capabilities that you specified or the resolved value.
<orkon> jgraham: this question came up around the unhandled prompt behavior and if you should get something back if you did not specify anything. Safari follows the spec, and Chrome and Firefox return the values always
<jgraham> q?
<orkon> jgraham: should we continue handling this per capability or handle it in a general way?
<orkon> q+
<jgraham> ack next
<jgraham> ScribeNick: jgraham
<simonstewart> q+
<jgraham> orkon: We would prefer to always return resolved capabilities but don't feel strongly. It seems like it might be easier for the users to return what's actually used by the session.
<jgraham> ack next
<jgraham> ScribeNick: orkon
<orkon> simonstewart: the returned capabilities are usually for the local end to figure out what the remote end supports
<jgraham> q+
<orkon> simonstewart: the criteria to decide should be if the client would need the information and correct the request based on the response
<orkon> simonstewart: the safe way is be to return everything. Otherwise, we need to decide on teh case by case basis
<jgraham> ack next
<simonstewart> q+
<orkon> jgraham: so returning it always seems to be the only backward compatible way to move forward. The only thing is that we do not return the full list of Firefox specific properties. It is possible that there are cases where the list of possible values/capabilities is too large
<orkon> jgraham: returning the defaults make a more uniform API
<jgraham> ack simonstewart
<orkon> simonstewart: there are some capabilities that you do not want to return in full, like proxy configuration. For properties it makes sense to exclude them or provide a subset
<orkon> simonstewart: perhaps we should put in the spec how to return the value if you need to return it
<orkon> jgraham: the spec has this but for many capabilities we do not default to returning values
<jgraham> q?