search

w3c / webdriver-bidi

Bidirectional WebDriver protocol for browser automation
https://w3c.github.io/webdriver-bidi/
378 stars 42 forks source link

Expose initiatorType and destination on network.Request #809

Closed jgraham closed 1 week ago

jgraham commented 2 weeks ago

Currently we have network.Initiator, which exposes some detailed information about the stack trace that generated the request on network.beforeRequestSent, plus a type field that's not well defined.

Fetch exposes initiatorType and destination and these are already used by other standards e.g. performanceTiming. Having data that directly corresponds to those other specs makes a good deal of sense so that e.g. performance measurements using WebDriver have the same fields with the same information as the DOM measurement APIs.

With this change we could remove Network.Initiator.type since that's redundant with this data, but keep the field for extra information about the stack that generated a request.

Preview | Diff

jgraham commented 2 weeks ago

It's still a little bit unclear to me how this corresponds to Network.ResourceType in CSP, but it seems like there ought to be enough information to compute most of those values from these fields (Ping doesn't have an obvious mapping, but the others seem likely to). That would require someone from Chromium to verify.

jgraham commented 2 weeks ago

This, plus removing Network.Inititator.type is a proposal for solving #698 and an alternative to #714.

whimboo commented 2 weeks ago

Overall, this looks good to me. However, I’d like to refer to @OrKoN first to clarify the question about Network.resourceType in CDP. It seems that destination might align closely with what resourceType covers, but there could still be some differences.

Would it be possible to adopt the values defined by the Fetch specification?

OrKoN commented 2 weeks ago

I think this change does not fully clarify https://github.com/w3c/webdriver-bidi/issues/698 (at least not in the same way Puppeteer currently expects the initiator to work, for example, by providing the referrer and the parser positions for non-script initiator types). The CDP version tries to cover the following use case: how do I track where does this particular request got initiated from providing the exact URL to a position in a resource that initiated the request if it is known. While this is difficult to spec, this spec change might not fully address that use case.

How do you propose to deal with the removal of Network.Inititator.type in terms of backward compatibility?

jgraham commented 2 weeks ago

The CDP version tries to cover the following use case: how do I track where does this particular request got initiated from providing the exact URL to a position in a resource that initiated the request if it is known. While this is difficult to spec, this spec change might not fully address that use case.

Right, this only covers the type part of Initiator, but it does make the data available through every stage of the request. I'm not suggesting we remove the parts related to the stack even though they are indeed difficult to specify and depend on.

How do you propose to deal with the removal of Network.Inititator.type in terms of backward compatibility?

Well Gecko currently hardcodes "Other" I think. From a CDDL point of view you aren't supposed to reject additional fields (although we could mark the field as optional and not have any steps to set it), so in terms of semantics it's really about what Chrome does here, and what clients depend on. Like if we shipped this for a bit, and then you started hardcoding the "other" value in Network.initiator.type for some additional time, and then we finally removed it, that would probably avoid breaking anyone. But it's not a perfect plan.

whimboo commented 1 week ago

@juliandescottes would you mind doing a final review from our side given that you mostly worked on the network features? Thanks.

jgraham commented 1 week ago

I assume we will handle updating the initiator field of beforeRequestSent in another issue/PR?

Yes.

css-meeting-bot commented 1 week ago

The Browser Testing and Tools Working Group just discussed Expose initiatorType and destination on network.Reques.

The full IRC log of that discussion <AutomatedTester> topic: Expose initiatorType and destination on network.Reques
<AutomatedTester> github: https://github.com/w3c/webdriver-bidi/pull/809
<AutomatedTester> jgraham: when we first did the networkj request events
<AutomatedTester> ... we had network.initiator which ahd a type field to mirror what was in cdp. We never really figured that out and it's not being used
<AutomatedTester> ... but now fetch has the same use cases for the initatorType and this PR has all of this
<AutomatedTester> ... and there is a plan that we can deprecate the previous way of doing this
<AutomatedTester> ... are there any remaining concerns on this proposal?
<whimboo> q+
<AutomatedTester> ack next
<AutomatedTester> whimboo: I wanted to mention this is a property that would fully unblock cypress sooner
<AutomatedTester> ... Cypress is planning a major release next year and they want to show that they have bidi support
whimboo commented 1 week ago

I assume we will handle updating the initiator field of beforeRequestSent in another issue/PR?

Yes.

There is https://github.com/w3c/webdriver-bidi/pull/714. Can this still be used or do we need something new?