You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I think we should consider preventing install if there is an app already installed that controls the start_url of the app, or the current document in the same-origin case. This is mostly to prevent this kind of use, which hinders the UA's ability to promote installation / know which urls belong to which app (and other problems cited in here. Then, when we solve w3c/manifest#996, devs can make sure the places they need to installed (if nested) fall outside of the outer app's scope.
I think this sounds like the right approach, and here are some initial pros/cons:
Pros:
Less likely to cause confusion around which app should open the content.
Aligns with the current install prompting behavior in chromium-based browsers
You can get into a state where two apps control the same path if an app with a smaller scope is installed first (e.g. example.com/app/cool-game) then a larger scope second (e.g. example.com/app).
Existing "Site as app"/"DIY apps" installed by the user could prevent nested apps from being installed (this issue already exists for browser-prompted installs)
The text was updated successfully, but these errors were encountered:
I would be OK with us saying that those manual apps don't prevent installing of nested stuff / are 'last on the list' when it comes to considering who 'controls' a url. That.... may make things even more complicated lol. But if we end up having problems here with manual apps blocking install, we could explicitly exclude those.
Originally mentioned here by @dmurph: #893 (comment)
I think this sounds like the right approach, and here are some initial pros/cons:
The text was updated successfully, but these errors were encountered: