[w3c/manifest] Manifest processing should not be a function of document URL (#668)

The [steps for processing a manifest](https://www.w3.org/TR/appmanifest/#dfn-processing-a-manifest) are currently defined as a function of both *manifest URL* and *document URL*:

> The steps for [**processing a manifest**](https://www.w3.org/TR/appmanifest/#dfn-processing-a-manifest) are given by the following algorithm. The algorithm takes a string *text* as an argument, which represents a manifest, and a URL *manifest URL*, which represents the location of the manifest, and a URL *document URL*.

This means that the entire identity of the app is uniquely determined by the tuple (*text*, *manifest URL*, *document URL*). Though practically, since *text* can be derived from *manifest URL*, it means just the pair (*manifest URL*, *document URL*).

The problem is *document URL*. The app can be interpreted differently depending on which *document URL* the manifest was referenced by. In reality, the *document URL* is only used in two places:

1. As the default value for `"start_url"`.
2. To check that `"scope"` is same-origin as *document URL*.

I maintain that the processing of a manifest should *not* be a function of the document URL. This means the app will potentially behave differently depending on which page the user was on when they installed the app, and we cannot meaningfully index or install an app from outside of a document (as Microsoft is currently doing).

We should:

1. Remove the default value for `"start_url"`, and require `"start_url"`.
2. Move the check that `"scope"` is same-origin as *document URL* outside of the steps for processing the manifest (so if that check fails, it means that the manifest is not valid *for that page*, as opposed to being an invalid manifest).

This means that the semantics of the manifest becomes a pure function of the *manifest URL* itself (and of course the manifest *text*), and thus it will behave the same no matter where you install it from.

Making the above change 1 will technically be a breaking change, but since sites can't rely on the default `"start_url"` (since it's dynamic) this should not be able to break any expectations.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/w3c/manifest/issues/668