emulation.setClientHintsOverride -> userAgentClientHints.setClientHintsOverride#393
Conversation
whimboo
left a comment
There was a problem hiding this comment.
The renaming looks fine to me but I have a couple more questions regarding the overall steps and internal data definitions. If those should be on its own PR feel free to move them out.
There was a problem hiding this comment.
For our BiDi emulation commands we have such maps on the BiDi session or remote end. Could we use the remote end definition from BiDi here?
There was a problem hiding this comment.
For our BiDi emulation commands we have such maps on the BiDi session or
remote end. Could we use theremote enddefinition from BiDi here?
This spec uses term "user agent" as a synonym to WebDriver's "remote end".
There was a problem hiding this comment.
So what should we follow then? Has the term from the actual spec the precedence I assume?
CC @jgraham.
There was a problem hiding this comment.
The spec gets to decide on its own internal definitions.
However.
The Infra definition of "user agent" is understood to be closer to WebDriver BiDi's "user context" than "remote end". Therefore, without any further investigation, if you are trying to use it for the latter you might be wrong.
(I think Infra made a mistake here; the argument is basically that web specs can't see outside their own storage partition anyway, so from their point of view defining a "user agent" as a single storage partition makes things easier because it's the biggest domain that a web spec might want to address. But of course that's not what anyone else means by "user agent" and WebDriver can see outside specific storage partitions, so it just means we need to avoid the term)
| @@ -1084,28 +1084,28 @@ | |||
| * [=struct/item=] named <dfn for="emulated client hints" export>emulated client hints per navigables</dfn>, | |||
| which is a weak map between [=/navigables=] and [=user agent client hints=], initially empty. | |||
There was a problem hiding this comment.
Other emulation commands need only a single map. Why do we have to maintain three of them for this command?
There was a problem hiding this comment.
Other emulation commands need only a single map. Why do we have to maintain three of them for this command?
This approach was suggested by extra headers and is used in several places in the main spec. I personally find it more readable and structured. Also it allows for more explicit global settings handling:
There was a problem hiding this comment.
Oh I read this wrongly. It's a single struct with individual maps as properties. That's fine then.
|
|
||
| 1. If |command parameters| [=map/contains=] "<code>userContexts</code>" | ||
| and |command parameters| [=map/contains=] "<code>contexts</code>", | ||
| return [=error=] with [=error code=] [=invalid argument=]. |
There was a problem hiding this comment.
It would be great if the order of the steps would be equal to those that we have in our BiDi spec, which would make it much easier to parse and implement. Maybe this can be fixed? Also I do not see a step that checks that at least contexts or userContexts are present.
There was a problem hiding this comment.
Also I do not see a step that checks that at least
contextsoruserContextsare present.
It is allowed to skip both contexts or userContexts and it would mean global setting. w3c/webdriver-bidi#956
There was a problem hiding this comment.
Ah ok, Not all of our existing emulation commands support that yet and I actually checked only those. :/ Thanks for pointing out.
912bf7e to
ca4a72b
Compare
There was a problem hiding this comment.
So what should we follow then? Has the term from the actual spec the precedence I assume?
CC @jgraham.
| @@ -1084,28 +1084,28 @@ A [=User agent=] has <dfn>emulated client hints</dfn>, which is a [=struct=] wit | |||
| * [=struct/item=] named <dfn for="emulated client hints" export>emulated client hints per navigables</dfn>, | |||
| which is a weak map between [=/navigables=] and [=user agent client hints=], initially empty. | |||
There was a problem hiding this comment.
Oh I read this wrongly. It's a single struct with individual maps as properties. That's fine then.
|
Now that it's using its own namespace I don't have further concerns. |
|
@miketaylr can you please review these changes? Thanks! |
3e5636e to
e85e188
Compare
|
@miketaylr PTAL |
|
Apologies for the delay - have been traveling for summits. @arichiv, do you mind reviewing? It may be a few days before I can take a look. |
arichiv
left a comment
There was a problem hiding this comment.
seems reasonable overall, not fully read-in on the motivation but if it makes web-driver side people happy the changes here seem mostly like a no-op (better defined, no changes in Chrome required).
|
@arichiv please consider merging |
…s.setClientHintsOverride SHA: 6cf1025 Reason: push, by arichiv Co-authored-by: github-actions[bot] <41898282+github-actions[bot]@users.noreply.github.com>
…tHints.setClientHintsOverride` Follow-up after WICG/ua-client-hints#393
…tClientHintsOverride` (#4053) Follow-up after WICG/ua-client-hints#393 --------- Signed-off-by: Browser Automation Bot <browser-automation-bot@google.com> Co-authored-by: Browser Automation Bot <browser-automation-bot@google.com>
…tHints.setClientHintsOverride` (#57681) Follow-up after WICG/ua-client-hints#393
…tClientHintsOverride` (#4053) Follow-up after WICG/ua-client-hints#393 --------- Signed-off-by: Browser Automation Bot <browser-automation-bot@google.com> Co-authored-by: Browser Automation Bot <browser-automation-bot@google.com>
…sOverride` -> `userAgentClientHints.setClientHintsOverride`, a=testonly Automatic update from web-platform-tests [wdspec] rename `emulation.setClientHintsOverride` -> `userAgentClientHints.setClientHintsOverride` (#57681) Follow-up after WICG/ua-client-hints#393 -- wpt-commits: 014898d321c48cff1d98f5dfb03d116e7210c13f wpt-pr: 57681
Addressing #391 by moving command to a dedicated
userAgentClientHintsdomain.Preview | Diff