This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.
The 'Web Manifest' spec wants to define a "navigation scope" that restricts the set of URLs that an application can be navigated to [1]. This works as a kind of fence that says: "The scope of this app is anything in http://example.com/foo". Meaning that the following are "in scope" for navigation: http://example.com/foo http://example.com/foo#bar http://example.com/foo/bar/ And the following are "out of scope": http://example.com/ http://example.com/bar#foo http://example.com/whatever The intent is to prevent a web application from being navigated to somewhere unexpected (e.g., by an advertisement). It would be nice if HTML's navigate algorithm accepted a URL to scope navigation to. Although it's possible to check if a URL is in scope prior to navigation, it's not possible for the Web manifest spec to do this during a redirect (without monkey-patching the HTML spec). Few more details: A web application only has one navigation scope. If the navigation scope is undefined in the web manifest, the user agent just runs HTML's navigate algorithm as normal. I expect that if a navigation is out of scope, then a security error would be returned. [1] https://github.com/w3c/manifest/issues/114
This seems very related to Service Workers' concept of what is in scope for a worker. Is there any effort to align these features?
See bug 27146.
(In reply to Ian 'Hixie' Hickson from comment #1) > This seems very related to Service Workers' concept of what is in scope for > a worker. Is there any effort to align these features? Yes, the way one determines if something is in scope of something else is the same. However, IIUC, I service workers don't relate to navigation of a browsing context.
Service workers relate to navigation: they control where the data comes from for the navigation.
(In reply to Ian 'Hixie' Hickson from comment #4) > Service workers relate to navigation: they control where the data comes from > for the navigation. Ok, I see. I'll track what comes out of bug 27146 and see if we can align somehow.
I'm going to close this as it's not actionable. My recommendation would be to write a monkey patch for the navigate algorithm and then file an issue or PR to see how and if we can integrate this.