Clarify the initiator steps

[OrKoN]

Issue #698

This PR clarifies the logic of how to compute various initiator types and makes the following changes:

• removes the requestId since it is already included in the network event that contains the initiator.
• adds a URL to hold the referrer for the initators that do not have a stack trace.
• clarifies that the line and column position should be based on the implementation-specific parser metadata that is currently not specified by web standards but usually is available for error reporting and DevTools.
• adds a note clarifying the purpose of the initiator: to give the user the information about how a particular request was triggered, so that the source of the request can be identified.

---

Preview | Diff

[OrKoN]

@juliandescottes @jgraham @whimboo I attempted to improve the initiator steps. There are still a few problems although it brings the steps closer to what is expressed by CDDL types. Problems:

1. I am not quite sure that there referrer would be an URL. The fetch spec mentions that it will be a URL or no-referrer during fetching. CSSOM spec seems to be always setting it without checking for no-referrer.
2. the parser positions are "implementation-defined" since I could not link to any spec.
3. the parser type is extended to cover the css initiators but it is a bit difficult to track what exactly fetch initiators define.

WDYT?

[juliandescottes]

Some nits, overall that looks good to me. Not sure yet how to retrieve the fetch initiator type on our side, but that shouldn't block landing this.

[jgraham]

I feel like if all the logic we need to map onto what Puppeteer expects is the fetch initiator type and isTopLevel we should consider just providing those directly and performing the mapping in the client.

[jgraham]

It's not clear to me if this is correct given e.g. @import rules (I don't know how CDP behaves)

[juliandescottes]

@OrKoN what do you think about the suggestion from @jgraham to only expose the fetch initiator + isTopLevel. Having the BiDi initiator differ from the fetch initiator could be confusing I think?

[OrKoN]

@juliandescottes I think the BiDi initiator is already different from the fetch spec: "parser" / "script" / "preflight" / "other these are the types currently specified. The issue with the fetch spec is that it is not clear how all those initiator types are computed (the fetch spec has a list but the computations seem to be scattered around a bunch of other specs?) and AFAIK our implementation does not implement all of them. In any case, I think we can postpone this then. In CDP, we do not have isTopLevel and fetch initiator types exposed so it would take some time to plumb them through and since there is no use case for exposing them directly, we can consider it later.