- From: Alex Russell <notifications@github.com>
- Date: Mon, 06 Apr 2015 11:30:35 -0700
- To: slightlyoff/ServiceWorker <ServiceWorker@noreply.github.com>
- Message-ID: <slightlyoff/ServiceWorker/issues/673@github.com>
In previous iterations of the spec, a property of the `FetchEvent` type allowed the developer to easily understand if they were responding to a potential navigation; e.g. `if(e.isTopLevel) { ... }`. This is now gone, nominally replaced by the [`context` attribute of a Request](https://fetch.spec.whatwg.org/#requests). This, however, doesn't actually provide the same information. @jakearchibald has made the (cogent) case that a different `Content-Disposition` for a `Response` might not result in a navigation. I'd like to untangle this and expose what we know about the request. I suggest that [`FetchEvent`](https://slightlyoff.github.io/ServiceWorker/spec/service_worker/index.html#fetch-event-section) be extended with a property that describes if the event corresponds to a potential navigation; straman would be `e.isNavigation`. *Bonus points*: the `Content-Disposition` handling is magical! It creates the ability for a response to not navigate a frame. This should be an API! In fact, it should be possible to `e.respondWith(/*something*/)` that _explicitly_ has this behavior in order to allow a SW to intercept navigations and drop them on the floor & `postMessage` to the client to effect an in-page transition. --- Reply to this email directly or view it on GitHub: https://github.com/slightlyoff/ServiceWorker/issues/673
Received on Monday, 6 April 2015 18:31:04 UTC