On 7/1/14, 10:54 AM, Anne van Kesteren wrote:
Good question. From what I remember the main motivation was having
something distinct from navigating the top-level browsing context. A
service worker might want to know whether it's "app" top-level
browsing context is being navigated or whether it's an auxiliary
browsing context.
So there are a few things to unpack here.
If I do a window.open(), then I now have two top-level browsing
contexts. One of them is auxiliary, one is not, right? Its possible to
then navigate that browsing context via more window.open() calls
targeting that auxiliary browsing context name, anchor clicks in that
browsing context or others, location sets, form submissions, etc.
So if what we really want to know is whether a navigation is associated
with an auxiliary browsing context or not, I think doing that via the
request context isn't a good fit; it's somewhat orthogonal to how the
request is being performed.
As long as we're here, is the associated origin of a request related to the
request context or the response? It would be good to make that clear.
A request's origin is set by the API that initiates the fetch.
OK. So this is the origin of the thing that triggered the fetch, basically?
A response does not really carry an origin.
I guess that depends on how you think about redirects. The origin of a
response is determined based on the URI it was actually gotten from,
which may not be the same URI that the consumer passed into fetch
initially, right?
-Boris
_______________________________________________
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform
