Re: [w3c/manifest] Processing the manifest is no longer a function of document URL (#834)

We have identified one potential breakage of existing behaviour with this change:

If you have a manifest with no (or invalid) `start_url`, then:

- Under the **current spec**, any shortcut URLs, [share targets](https://w3c.github.io/web-share-target/) or [file handlers](https://github.com/WICG/file-handling/blob/master/explainer.md) (the latter two in WICG incubation) will be allowed _if_ they are within scope of the parent directory of the document URL.
- Under the **proposed text**, any shortcut URLs, [share targets](https://w3c.github.io/web-share-target/) or [file handlers](https://github.com/WICG/file-handling/blob/master/explainer.md) will be invalidated unconditionally.

(This is because under the current spec, the scope is set to its fallback value _before_ other URLs are compared using "within scope". Under the proposed text, the scope is set to undefined, then the other URLs are compared using "within scope", and then the user agent has the option of setting the scope to its fallback value.)

For example, say that you are in a document at `https://example.com/foo/index.html`, with the following valid manifest:

```json
{
  "scope": "https://anothersite.com",
  "icons": [{
    "src": "https://somecdn.com/icon.png"
    }],
  "shortcuts": [{
    "name": "Click me",
    "url": "https://example.com/foo/click.html"
  }]
}
```

If you quickly eyeball this manifest, you'll see that both the icon and shortcut are on a different origin to the scope, so you might initially think both the icon and shortcut would be rejected. However, icons do not need to be on any particular origin, so those are OK. You'd think, though, that the shortcut would not be valid.

What actually happens, under the **current spec**, though, is:
1. Since there is no `start_url`, the `start_url` defaults to `https://example.com/foo/index.html`.
2. Since `start_url` is not within scope of `scope`, `scope` is changed to `https://example.com/foo/`.
3. Since the shortcut's `url` is now within scope of `scope`, it is valid.

In fact, the shortcut is valid in this case, which I find quite gross, as the validity of the shortcut depends on which URL you were on when you installed the manifest. If you installed the exact same manifest from `https://example.com/foo/bar/`, the shortcut would not be valid.

Under my **proposed text** for this PR, the above case would invalidate the shortcut unconditionally. Now what would happen is:

1. Since there is no `start_url`, the `start_url` defaults to undefined.
2. Since `start_url` is not within scope of `scope`, `scope` becomes undefined.
3. Since the shortcut's `url` is not within scope of `scope`, it is invalidated and dropped. (In fact, all shortcuts, share targets and file handlers will be invalidated.)
4. At the top level algorithm, the user agent MAY set `start_url` to `https://example.com/foo/index.html`, and `scope` to `https://example.com/foo/`. But the shortcut remains invalid.

This is a minor breaking change, but I think it's a good change, because:

1. It's bad for the validity of those other URLs to depend on the document URL.
2. This change will only affect websites that have no or invalid `start_url`.
3. This change only affects very new or experimental APIs (shortcuts, which has not become available in any major browser, share target and file handlers, which are still in incubation). Share target is the oldest of these APIs, but as far as I know, its only implementation (Chrome for Android) requires a WebAPK which requires a valid `start_url`. So this won't break any stable APIs.

-- 
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/pull/834#issuecomment-653291942