Re: [fetch] Introduce convenience property for request's context (#93)

I have been implementing the various RequestContext types in Gecko, and based on my experience, I think we need to pause and agree on what RequestContext is supposed to represent first.

Currently, RequestContext represents values on three axes:

* What a specific thing that is being loaded from the network is (for example: "font")
* How a specific thing is being loaded (for example: "hyperlink")
* Where (as in, what specific tag, for example) a request is coming from (for example: "frame" vs. "iframe")

This can lead to a number of difficult questions to answer.  For example: "How should we represent an audio file being downloaded from a <video> tag?", "How should we represent a hyperlink click that results in a download inside an iframe?" and so on.

As far as I can tell, there are two things that make these questions difficult to answer:

* It is not clear which one of these axes a specific RequestContext value appears on (for example, the question about loading audio inside a <video> tag.)
* It is not clear what specific value should be used in specific cases, since the respective specs usually are not based on top of Fetch.

I think it may make more sense to split the first two axes into two completely separate enums.  The third axis seems not too valuable to support, as far as I can tell.

FWIW, in Gecko, I'm planning to disable RequestContext completely so that we don't have this as a blocker to ship service workers, until the spec situation gets resolved.

---
Reply to this email directly or view it on GitHub:
https://github.com/whatwg/fetch/issues/93#issuecomment-125289983