Re: [w3c/manifest] Steps for processing shortcut member are very vague (#831)

Thanks for filing this, Dom. A reminder that we can't really know whether specs are "complete" until we try to implement them!

> * should shortcut item URLs be restricted to be within the scope of the manifest? The spec seems to imply this ("The shortcuts member is an array of ShortcutItems that provide access to key tasks within a web application."), but the processing algorithm doesn't prescribe any checks here. It seems weird to allow arbitrary URLs.

Good call. IMO, shortcut URLs should be restricted to the scope of the manifest (though technically they don't have to be, and there aren't any security ramifications of not, since the app could just redirect to another origin anyway, I think it's most sensical to enforce this restriction).

> * when should developer warnings be issued when parsing the member?

IMO I think it's a mistake that we specify developer warnings at all in the specs. It should be considered part of the UA's UI when to display developer warnings.

That said, given that the rest of the manifest spec says to display developer warnings, we should add that text here too.

> * when should items be ignored (presumably when `name` or `url` are empty?)

Arguably we could consider it valid if it has a `short_name` but not a `name`. But I think the most reasonable is to ignore items missing a `name` or `url`.

Overall, it's best to restrict now, and remove restrictions later, than start too open.

So my recommendations would be:

1. The [steps for processing the `shortcuts` member](https://www.w3.org/TR/appmanifest/#dfn-processing-the-shortcuts-member) should be rewritten as a numbered list, rather than a single paragraph.
2. The algorithm currently doesn't actually return anything. It just processes things and discards the result. Structure it like the [steps for processing the `related_applications` member](https://www.w3.org/TR/appmanifest/#dfn-processing-the-related_applications-member), where you create an empty array, then append each processed item to it, and return the array at the end.
3. If either `name` or `url` is missing, do not append the shortcut to the output list (effectively ignoring it), and issue a developer warning.
4. If the URL parsing is failure, issue a developer warning and do not append the shortcut to the output list.
5. If the parsed URL is not within scope of the manifest, issue a developer warning and do not append the shortcut to the output list.
6. Add to [`url` member](https://www.w3.org/TR/appmanifest/#url-member) of `ShortcutInfo` the text: "... is the URL within the application's scope that opens ...". (Note that this is mostly informational; it doesn't need specific MUST requirements around it because we already specify how to parse it in the processing steps.)

Having typed up all that, I think I'm just gonna go ahead and make those changes.

-- 
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/831#issuecomment-562407956