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

mgiuca commented on this pull request.



> @@ -1982,13 +1983,11 @@ <h3>
         <p>
           The steps for <dfn>processing the <code>start_url</code> member</dfn>
           are given by the following algorithm. The algorithm takes a
-          <a>USVString</a> <var>value</var>, a <a>URL</a> <var>manifest
-          URL</var>, and a <a>URL</a> <var>document URL</var>. This algorithm
-          returns a <a>URL</a>.
+          <a>USVString</a> <var>value</var>, and a <a>URL</a> <var>manifest
+          URL</var>. This algorithm returns a <a>URL</a> or undefined.

Essentially, that would mean if `start_url` is invalid, it defaults to the parent directory of the manifest file.

Currently, Chrome and Firefox (at least) do not consider a site installable if `start_url` is missing or invalid, behaviour which I am attempting to enshrine by returning undefined (effectively treating it as missing) and by explicitly saying the document is not installable if `start_url` is not present. I think it's desirable / conservative to fail in these bad cases, rather than try to come up with some "reasonable" default.

Also this default can go horribly wrong: if the manifest is hosted on a CDN, this would cause both the `start_url` and `scope` to be set to the parent directory on that CDN, which would likely be a 404 or a directory listing page.

-- 
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#discussion_r368380405