[Web Install] Using manifest_id as an install_url for cross-origin install will cause errors & flakiness, and encourage poor practices
dmurph opened this issue · 2 comments
The manifest id is not guaranteed to be loadable, it's just parsed as a url. Last I checked >10% of parsed manifests specify a custom id. So this will not work for some number of sites.
If it DOES work for a site, my concern is that allowing this shorthand will encourage foot-gun behavior, where 'for now' the manifest_id can be loaded which will happen to have the manifest.json linked, but:
- That is not guaranteed to not change, and by allowing this to happen it might drive a dev misconception that we 'magically' figure out where the app is.
- This is almost never a good
install_url, which will avoid loading expensive resources, not be behind an auth gate, etc.
While sometimes it might seem redundant, forcing the specific install_url will help avoid future problems for devs, and encourage web apps to create & publish install_urls that are optimized for install.
I had a long chat with Reilly here - andI think that I'm wrong. I think this behavior is OK, as long as it's the cross-origin API.
The conclusion we came to is that the two APIs here are really most importantly differentiated as "install this site" or "install from background web contents". They should likely be named different things as well. I'll make a new issue for this feedback.
@reillyeon had a good point that by allowing manifest_id to be loaded here, it encourages developers to make their manifest_id their install url - and by surfacing the 'slow install' problem to developers using this API it helps them realize they need a good install_url as well.