emulation.setUserAgentOverride
#947
Conversation
index.bs
Outdated
| WebDriver-BiDi [=remote end=] must have an implementation that runs the following | ||
| steps: | ||
|
|
||
| Issue: get |related navigables|. |
There was a problem hiding this comment.
I found 2 usages of the "default User-Agent value":
- Set a header for network request.
- NavigatorId's "appVersion" and "userAgent".
We need to fins a way to specify what "related navigables" means in those cases.
There was a problem hiding this comment.
I guess we could propose an update to the fetch and html specs? I think there is a way how find related navigable for an HTTP request (like in interception) and for a document, does it work here?
There was a problem hiding this comment.
Yeah, I think we should attempt creating patches for the HTML and Fetch spec. WDYT?
There was a problem hiding this comment.
For reference the algorithm we use to map request to navigable is https://www.w3.org/TR/webdriver-bidi/#get-navigable-for-request
To hook from the fetch spec, you can look at the fetch PR at https://whatpr.org/fetch/1540.html#concept-http-fetch (we still haven't landed this so it makes a bit hard to follow the BiDi/fetch integration)
There was a problem hiding this comment.
I tried another approach
Initial draft of `emulation.setUserAgentOverride` command. Requires defining a list of related navigables for the "default User-Agent value" caller.
sadym-chromium
force-pushed
the
sadym/emulation.setUserAgentOverride
branch
from
e22449c to
989153d
Compare
| 1. If [=default User-Agent value=] was accessed during execution of the | ||
| [=HTTP-network-or-cache fetch=] algorithm with |fetchParams|: | ||
|
|
||
| 1. Let |request| be |fetchParams|’s [=request=]. | ||
|
|
||
| 1. If |request|'s [=request/client=] is not null, let |related navigables| | ||
| be the result of [=get related navigables=] with |request|'s | ||
| [=request/client=]. | ||
|
|
||
| 1. If [=default User-Agent value=] was accessed from [=NavigatorID=] interface: | ||
|
|
||
| 1. Let |realm| be [=current Realm Record=]. | ||
|
|
||
| 1. Let |environment settings| be the [=environment settings object=] whose | ||
| [=realm execution context=]'s Realm component is |realm|. | ||
|
|
||
| 1. Let |related navigables| be the result of [=get related navigables=] given | ||
| |environment settings|. |
There was a problem hiding this comment.
WDYT about this approach? @OrKoN @juliandescottes @jgraham ?
There was a problem hiding this comment.
@juliandescottes @jgraham WDYT about this approach?
There was a problem hiding this comment.
From a maintenance perspective, I prefer adding hooks in the relevant specs because otherwise the other specs might change and break the relationship with BiDi unintentionally.
From the point of view of someone trying to read and implement the specification, you still need to jump between the two specifications to understand the behavior. Possibly even harder to follow because you need to identify all the spots in the other spec which access [=default User-Agent value=], which sounds painful.
The main added value of this approach is that we don't have to update other specs, but apart from that hooks seem preferable to me. Is there something which makes it more difficult for the NavigatorID case? For fetch we already have pending hooks in whatwg/fetch#1540 so for consistency it also seems better to stick to hooks.
Initial draft of
emulation.setUserAgentOverridecommand. Requires defining a list of related navigables for the "default User-Agent value" caller.Preview | Diff