URL Scope to which the manifest applies

[annevk]

Given that it still seems likely we are keeping scoped service workers, manifests should adhere to the same URL scope somehow.

[marcoscaceres]

Related: w3c/ServiceWorker#137 (comment)

[marcoscaceres]

Deferring to v2 or later.

[annevk]

How can you defer this?

[marcoscaceres]

It can be defined as an extension to this spec in the SW spec.

[annevk]

How would that work?

[benfrancis]

See also, a thread on Mozilla's dev-b2g mailing list https://groups.google.com/d/msg/mozilla.dev.b2g/r6zAZfEBAI8/qvSmGpAPAJMJ

This is also important for navigational purposes (see #142).

The spec defines properties like "display" which define characteristics of the window in which the bookmarked app is opened, but under what circumstances should those options be applied?

Once a browsing context has been created it can navigate to any URL. Does the "standalone" or "fullscreen" display mode still apply if I navigate outside the app to an unrelated web page from another origin? What defines "outside the app" exactly?

My conclusions so far from that thread are that by default the scope of an app is the origin of the manifest. But there are cases (like multiple apps per origin) where you want to be able to carve the origin up into multiple apps, or into app content and general web content.

In the thread I suggest a manifest property called "scope" for this purpose, which contains a list of strings (URLs with wildcards or regex, but relative to the origin of the manifest URL like the start_url) which define the scope of the app. Two apps with overlapping scope can not be installed.

{
"name": "Google Calendar",
...
"scope": ["/calendar_", "/some_other_parts_of_the_app/_"]
}

Whenever a URL is navigated to it is matched against the list of "bookmarked" origins. If there is a match then it is matched against the scope property of the corresponding manifest(s) if present. If there is still a match then the URL is opened in the app defined by that manifest, with the properties defined in the manifest. If there is no match then the URL is opened inside a normal browser window.

This is similar to the "urls" property in the manifest of Chrome Hosted Apps, except that it is a path relative to the origin rather than an absolute URL which can be from any origin. This is because allowing multiple origins may be open to abuse where an app registers to handle URLs from another origin. To prevent that I believe Chrome Hosted Apps require developers to prove that they own a given domain name, which is a centralised tricky process that requires the manifest be hosted by the app store. By restricting the scope at maximum to the origin of the manifest we can already deduce that the author of the manifest has a certain level of ownership over or access to that origin.

If no scope is defined, should the scope be the full origin of the manifest, or restricted to just the start_url?

I had not considered how this might interact with scope of ServiceWorkers so I'm interested to find out more about how that works.