Re: [w3c/manifest] beforeinstallprompt : Prompting user makes it to hard to discern whether the user truly wanted to "install" a web app (#835)

> Having this event allows for enabling experiences like Microsoft showed with their [`<pwa-install>`](https://github.com/pwa-builder/pwa-install) custom element that now has to take a special [code path](https://github.com/pwa-builder/pwa-install/blob/463a8af46027bee16c518de8ca2eab1b3368bd20/src/pwa-install.ts#L505-L506) for dealing with iOS.

That's exactly the kind of a thing we don't want to allow. We don't want websites to have its own UI to initiate some kind of browser UI to save / install a web app to home screen.

> Concluding, if Safari showed a subtle badge like Samsung Internet that then entered the regular share sheet "Add to Home Screen" flow at the "Cancel"/"Add" state shown in the screenshot below and that respected the icons from the Web App Manifest (my related [WebKit bug](https://bugs.webkit.org/show_bug.cgi?id=183937)), this would put the user in full control and not annoy them.

Indeed but in that scenario, there is no need for this event because such an UI is by definition non-intrusive. I feel like I keep repeating myself but the issue here is that we don't want to give web apps / site control as to when or how the ability to save a web app / website to home screen is presented to the user.

> The real issue is the automatic "mini info bar" which shouldn't be automatic (or shouldn't exist at all) but let the developer decide when he can inform the user that the application is installable (and allow him to install it with the same experience despite browsers differences) is a must have.

I understand you and some other developers feel that way, but this is precisely what we're objecting. We don't want to give away that control to web apps / sites.

-- 
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/835#issuecomment-565123787