Re: [w3c/manifest] Clarify behaviour of a page linking to a manifest that is not within scope of that manifest (#784)

@marcoscaceres wrote:
> However, it a valid issue that if the manifest is missing a start URL, and the current URL is out of scope, we end up in a strange (undefined) situation.

Is it undefined? My understanding is that in that situation the start URL would be set to the document URL and the scope would be overridden from the start URL to make it in scope.

Regarding Chrome's behaviour, section [4.2 Launching a web application](https://w3c.github.io/manifest/#launching-a-web-application) says that:

_"target URL, if given, MUST be [within scope](https://w3c.github.io/manifest/#dfn-within-scope-0) of manifest."_

If I've understood correctly then what Chrome is currently doing is essentially immediately launching the app after installing it, but at a target URL outside the scope of the app, which arguably doesn't conform with the specification (see also #995).

@marcoscaceres wrote:
> I like this solution:
> 
> > Explicitly state that if the current page URL is not within the scope of the manifest, the manifest should be ignored for that page (use the default/null manifest instead). This would prevent the page from influencing the display or triggering installation if it is out of scope.

What would it mean to "ignore" a manifest? Refuse to install it? What is "the default/null manifest"? As I understand it currently all members of the manifest are optional in the specification so technically even an empty manifest `{}` (or invalid JSON, which gets replaced with an empty map) is installable, with the processed manifest populated with the bare minimum defaults that can be derived from manifest URL and document URL (though in practice implementations do impose their own minimum requirements).

@christianliebel wrote:
> Our spec does not define what should happen after installation

The current specification also doesn't define a process for actually installing an app, only launching an app that has been installed.

It is not ideal that there are various circumstances under which the processed start URL, scope and ID of an app may be different depending on the page from which they are installed. But short of making some members mandatory, defining the process for installing an app (and/or minimum installability criteria), or changing the defaults used for missing members, I think this can only be worked around with UI design and recommendations of best practices.

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

Message ID: <w3c/manifest/issues/784/2473589318@github.com>