Clarify the logic to compute the initiator type of a request

[juliandescottes]

From the current spec https://w3c.github.io/webdriver-bidi/#get-the-initiator

TODO: Get the type. It’s not quite clear how this ought to work; the CDP data depends on whether the navigation was kicked off by the parser or by script (so e.g. inserting an image from script causes the initiator to be "script"), but that doesn’t correspond to anything in Fetch.

The initiator's type can be one of "parser" / "script" / "preflight" / "other". "other" is the default, "preflight" is dedicated to CORS preflight. We should clarify in which cases the type should be "parser" or "script".

When using fetch or xmlhttprequest from a script, the type should be "script". When loading resources based on the parsing of the initial document, the type should be "parser". So we should probably focus on scenarios where elements are added via script but still rely on the parser. @OrKoN can you or someone from Google share more details on how CDP determines the initiator type?

For comparison, Firefox DevTools has a handful of additional initiator types such as "img", "font", "stylesheet". For instance if a request is done in order to retrieve the image of an img element, the type is always "img" regardless of how the element was created.

[OrKoN]

The initiator type in the WebDriver BiDi spec is probably closest to https://fetch.spec.whatwg.org/#concept-request-initiator

Things like "img", "font", "stylesheet" match resourceType in Puppeteer and are currently not in WebDriver BiDi spec. This probably matches https://fetch.spec.whatwg.org/#concept-request-destination or https://fetch.spec.whatwg.org/#request-initiator-type

To be honest, I am not sure Fetch defines these well (perhaps we could use the table mentioned in the fetch spec).

I can try to trace how it is implemented in CDP but I am not sure it is very well defined there.

[css-meeting-bot]

The Browser Testing and Tools Working Group just discussed Clarify the logic to compute the initiator type of a request.

The full IRC log of that discussion

<AutomatedTester_> topic: Clarify the logic to compute the initiator type of a request
<AutomatedTester_> github: https://github.com/w3c/webdriver-bidi/issues/698
<AutomatedTester_> orkon: we have an network initator which has a lot of TODOs
<AutomatedTester_> ... and we have been working throuh use cases in puppeteer
<AutomatedTester_> ... and we have been looking at the entire chain of the network
<AutomatedTester_> ... the current spec is missing the URL to show where the request has been started from
<AutomatedTester_> ... the ideal solution here would be to specify the initiator if possible. I know Chrome doesn't support it but we will look into how this could work
<AutomatedTester_> ... so the next question is would we want to align with the fetch spec ?
<jgraham> q+
<AutomatedTester_> ... it is feasible to keep track of the line number and position if another document initates the request
<AutomatedTester_> ack next
<AutomatedTester_> jgraham: the spec here didn't have it as we didn't know what clients might have
<AutomatedTester_> ... and we didn't know if things in the fetch spec are exposed... and I think we need to go investigate this a lot more
<AutomatedTester_> ... and we can take a proposal here to start from fethc spec. If there are things missing from the spec we need to figure that out
<AutomatedTester_> ... and if we need to add that to the fetch spec accordingly. so if we can write this up as a proposal so we can go figure out if this is something we can implement and then get back to you
<AutomatedTester_> orkon: I think for the most part I think that is fine but where in comes to the parser state that is not documented anywhere
<AutomatedTester_> ... and we know that if things are initated from a css file we have no way of knowing hwere it started
<AutomatedTester_> jgraham: for the parser stuff... we can see if the can expose them as we know devtools can show that data
<AutomatedTester_> ... it seems possible but we don't have this specified anywhere. we can say we will do a best effort
<AutomatedTester_> ... so we can avoid rewriting CSS and html spec to keep state
<AutomatedTester_> orkon: ok... I will go write a proposal on this then

[OrKoN]

Related https://github.com/whatwg/fetch/issues/1563