beforeinstallprompt : Prompting user makes it to hard to discern whether the user truly wanted to "install" a web app

[rniwa]

Prompting the user to "install" a website (via beforeinstallprompt) makes it hard to tell whether the user actually wanted to save the website for later use, or the user just wanted to pass through the prompts encountered before using / while the web app.

If we're trying to gate any feature only to installed apps, then it goes directly against the goal of differentiating websites that the user trusts; by the virtue of eagerly asking the user to install an app, we've decreased the likelihood that the user intentionally did so.

[rniwa]

But those permissions are directly associated with the action user is attempting to take (e.g. join a video conference)

That depends on the site. A "good" site will have a "join video conference" button which asks for cam permission and thus it's obvious to the user from context why it's asking for permission. Just as a "good" site will have an "install me" button which calls BIPE.prompt()* and thus it's obvious to the user from context why the UA is prompting to install.

"Good" sites are kind of irrelevant here.

Of course, there can be a "bad" site that asks for cam permission with no apparent context, at which point a savvy user might say no, or a naive user who just wants to click through everything might say yes. Similarly, a "bad" site could ask for install with no apparent context, at which point the same user might say no or yes. Basically the same argument being applied here applies to all of the other APIs that ask for permission.

An important thing here is that it's more apparent to the user that the website may need camera access if one is joining a video conference. It's unclear why a website needs to be saved to home screen. Again, permission prompts are bad and should be avoided whenever possible.

and the permission granted won’t persist once the browser exits

Ah I see. I didn't realise Safari revoked all permissions at shutdown. That is an important difference. But since installation shouldn't be granting any permissions, it shouldn't matter (see Controlling Access to Powerful Web Platform Features).

Again, we (Apple's WebKit team) don't necessarily agree with this particular Blink / Chromium policy / strategy / approach.

On a somewhat orthogonal point, I find it rather concerning that multiple Google representatives keep referring to some kind of Blink / Chromium policy or implementation details as supporting details when making a point in this issue. Since the whole point of having multiple independent implementations is that they're independent, I respectively ask everyone involved in this and future discussions from refraining from using any kind of Blink or Chromium specific policy or strategy as a way to mitigate whatever Web API concerns we raise.

[marcoscaceres]

is Mozilla actually opposed to this API on the grounds that @rniwa is elaborating here,

Yes, for exactly the reasons @rniwa outlined. I've discussed this with Firefox team/product owners on multiple occasion over many years and they've always opposed it and come to the same conclusion. Mozilla folks identified this problem in 2015 (my comment is a reflection of internal discussions).

However, I was personally optimistic Firefox would do something similar to Chrome from a install-UI perspective - but that never materialized.

or another reason, or have you just never implemented it for lack of time?

I indeed did implement BIP in Firefox, but we never shipped it - as again, Firefox UX folks don't believe it's a necessary API for the reasons above: The way Chrome does the install prompt is UA specific - hence there won't be any install prompt for Firefox. If that changes in the future, then BIP should become part of the standard again.

[kenchris]

^ @NotWoods @andreasbovens

[NotWoods]

I agree with what Marcos said. Firefox Preview will have a similar install flow to current Firefox for Android so nothing is changing there.

[vincentmorneau]

As a web developer who is currently building PWAs, I find this discussion appalling.

My users are struggling in Firefox, but Safari even worst. I understand the concerns about BIP but you are offering no alternatives. At the end of the day, this results in a bad experience for users. Plain and simple.

And where does that leave us web developers? It looks to me that Firefox and Safari would prefer we build native apps instead.

[ecjs]

I agree with @vincentmorneau here. It's just baffling. I mean I get it from the higher-ups at Apple...PWAs taking off hurts App Store profits...but its strange to have developers in here giving these half-baked reasons that really don't add up at all. It's even more strange to have Mozilla supporting this kind of rhetoric. It's anti-web. We are creating more walls/barriers than necessary. Having some badging that indicates install-ability is great and welcomed, but PWA adoption, which is something the web needs...for reasons like Electron....will be severely throttled by these positions being taken by Apple/Mozilla.

You either want web apps to be installable or you don't. If you want it, then commit to it. If you want them installable, you want it to be as frictionless as possible. Otherwise, it's easier to get a user to just download a .dmg or .exe file. Do we really want that?

And whats funny, Apple says it doesn't really want web apps in the App Store. You have developers afraid to use frameworks like React Native because of some of these new policies. Personally, I think there are other things going on here that are unrelated to some of the points being brought up by @rniwa...and those things are related to App Store profits. PWAs taking off would potentially hurt those profits. I am just surprised to see Mozilla taking the same position.

Electron is not what we want. But it will be what we deserve if we don't do this the right way. I say we because we are all one large developer community trying to make the web a better existence. Installable PWAs are not just bookmarks.

[jyasskin]

@vincentmorneau @ecjs FWIW, I read Mozilla's position as saying they intend to show the app-install prompt, just in a way that's unobtrusive enough to not need a way for developers to turn it off with the beforeinstallprompt event. Their prompt looks pretty reasonable from that perspective:

This is very different from Safari's stance of never encouraging web users to add websites to their home screens.

[NekR]

@jyasskin that prompt is uncontrollable and intrusive, just as random popups on websites. It shows immediately when you open a website, even if you're not logging in. The only way to prevent Firefox to show that on-load, is to not serve Web Manifest until user is logged in, which is weird.

That said, beforeinstallprompt would allow to not show that popup on page load, but rather show it when user logged in or at another "happy moment".

[NekR]

I like this part from @mgiuca's comment:

Also, it is entirely up to the developer what "prompting" means. If you don't want to show a modal dialogue, you could consider responding to a call to the prompt() method by simply flashing or wiggling the install button in your browser UI. You can do anything you want with your browser UI.

The UI doesn't have to be "prompting". It may just "highlight" the ambient badge button. Or show a tooltip which says "You can install this web app by tapping this button". Tapping on tooltip itself would do nothing.

Possibilities are not limited here, but the problem is -- the thing itself is not wanted. I'm starting to think there is more to this issue than simply "we don't want to be intrusive to users".

[ecjs]

@nekr that is my understanding as well. Seems odd that they would be against having some sort of API for installing web apps..that requires some sort of user-initiated action, like a <button> click. I'm curious why Mozilla thinks its "not needed", when in fact, developer support seems to be quite high.

as @marcoscaceres stated:

I think that leads to the conclusion that the API is not needed

[jyasskin]

@NekR The Firefox prompt starts as just the house icon in:

which I think isn't intrusive, although it does show even when you're not logged in. (Perhaps a use case for setLoggedIn...) I'm not saying you're wrong to want this, just that Firefox's and Safari's positions are pretty different.

[marcoscaceres]

I understand folks are frustrated, but I remind everyone of our code of conduct. Please keep discussion civil and refrain from speculating on why companies have chosen to implement their UX in certain ways. If the discussion becomes accusatory I will have no option but to lock this issue.

[marcoscaceres]

Just noting that Firefox Preview is - as the name suggests - "a preview" of what we are working on... and we will be experimenting a lot with how we do install prompts (if we do them at all!) over the next year or two as we gain experience in the area. However, don't take what is there today as any indication of what will be there tomorrow or completely gone the day after....

[rniwa]

You either want web apps to be installable or you don't.

This seems like a classic case of false dilemma.

If you want it, then commit to it. If you want them installable, you want it to be as frictionless as possible. Otherwise, it's easier to get a user to just download a .dmg or .exe file. Do we really want that?

That doesn't logically follow. I find it much easier to visit a website in my browser than having to go to App Store or Play Store & download hundreds of megabytes of binary. The biggest strength of the Web, compared to native platform, is the reach in my view because of how easy it is to go to any website.

On the other hand, I would find it annoying if each one of those websites kept asking me to allow notifications or save it to home screen & will probably use web browser less if I had to constantly deal with that.

This is very different from Safari's stance of never encouraging web users to add websites to their home screens.

I don't think either Apple's WebKit team or Safari team ever said that; at least I'm not aware of any stance or policy to discourage users to save websites on home screen. Had that been the case, we probably would have gotten rid of the feature entirely.

On a related note, I find it reprehensive that some people feel comfortable making baseless accusations of companies or people. I get that you might be frustrated with the way current UI works in Safari on iOS but that's not a reason to make up & spread conspiracy theories about others. Let's not do that.

[Splaktar]

"Good" sites are kind of irrelevant here.

As a developer, I find this worrying. As far as I understand it, "good sites" are the ones who are pushing for this feature to be implemented. While I understand that the title of this issue is focused on "bad sites", abuse, and confusion; calling "good site" developers and their product team requirements "irrelevant" seems a bit heartless and rude.

I'm happy to hear that Mozilla plans to try out some ambient badging strategies for surfacing a non-intrusive install action.

I continue to be unhappy with WebKit's "perspective" and vision of PWAs, especially the current implementation of the Add to Home Screen browser UI. I would like to see more proposals (solutions) and activity in the PWA space from WebKit.

I'm grateful for the Chromium team to be pushing forward and adjusting proposals and implementations in the PWA area. I'm happy that they are willing to share their references, policies, and insight while being open to feedback and input.

It will be unfortunate if beforeinstallprompt is removed from the spec, but all I am really concerned with is giving developers the tools to implement high quality UX PWA installation flows. If this comes in the form of another proposal, I'm fine with that. I don't want more unsolicited pop up prompts in the web content area (I don't see anyone advocating for that), but I do feel that giving developers the ability to have some control over the timing of the installation process is critical.

[rniwa]

"Good" sites are kind of irrelevant here.

As a developer, I find this worrying. As far as I understand it, "good sites" are the ones who are pushing for this feature to be implemented. While I understand that the title of this issue is focused on "bad sites", abuse, and confusion; calling "good site" developers and their product team requirements "irrelevant" seems a bit heartless and rude.

Let's recall the context here. We were discussing potential ways this prompt / UI can be abused.

Suppose someone proposed raw memory access API for the Web, which allows random physical address space access in user's machine. If someone were to reply to an issue raised by another saying that "a good website can display a carefully worded warning to users so that they won't accidentally enable it", I'd dismiss that as irrelevant because when we're talking about the threat models and abuses, we're not concerned with well behaving parties.

I continue to be unhappy with WebKit's "perspective" and vision of PWAs

Could you point me to what perspective and vision we shared about PWAs? Also, that topic is best discussed in the WebKit community (e.g. webkit-dev) instead of W3C, which is a venue for standardizing Web APIs.

If this comes in the form of another proposal, I'm fine with that. I don't want more unsolicited pop up prompts in the web content area (I don't see anyone advocating for that), but I do feel that giving developers the ability to have some control over the timing of the installation process is critical.

Unfortunately, this is a part of the concern we have about this API. It's increasingly common for websites to lock out Safari on iOS and force users to download native apps instead. Adding the ability to control when a web site / app can be saved on home screen can proliferate that further. If it's just a hint to UA that could be ignored, then I don't think it's useful anyway.

[vincentmorneau]

I believe all "good site" developers care about is the BeforeInstallPromptEvent.prompt() method. If the beforeinstallprompt event goes away from the specs, so be it. I agree it feels awkward to have to preventDefault() to offer a "good site" UX. But please w3c, keep a spec to manually prompt the install.

Could you point me to what perspective and vision we shared about PWAs?

@rniwa In Safari, "Add to home screen" is hidden at the secondary level of the share tray. I think that says it all about Webkit's vision on PWAs. But I'd love to be proven otherwise and I'm sorry if this is not the right channel to discuss it.

[marcoscaceres]

But I'd love to be proven otherwise and I'm sorry if this is not the right channel to discuss it.

This is not the right place to have this discussion.

I'm locking this issue as I feel we have enough information to make a decision.