Allowing only site-triggered install prompt

[photopea]

Hi folks, do you really like this idea, that a user-agent will "analyze" a website somehow and decide, if it is appropriate to show an install prompt? It can be disturbing, if the "analysis" is wrong. I also hate the fact, that a browser makes such decissions (browser manufacturers can show the prompt more often for websites, which pay them, nobody will ever find out). I think that the browser should be as "invisible" as possible, and each action should come from the user, or from the website with a users permit.

I am using the following code to be able to trigger an install prompt.

window.addEventListener("beforeinstallprompt", function(e){  e.preventDefault();  myEvent=e;  });
if ("serviceWorker" in navigator)  navigator.serviceWorker.register("sw.js", { scope: "./" });  
//  I call myEvent.prompt();  later, when user clicks Install

The problem I have is, that if both the website and the user want the site to be installed, the user-agent itself becomes an obstacle (by not dispatching "beforeinstallprompt"). What about replacing it all with this:

navigator.install();

It can throw an exception, when installing is not appropriate. If you think there is a risk of "attack" by calling it too often, we can deal with it the same way we deal with alert(...). Imagine if alert(...); worked only on Mondays and only between 12th and 37th minute of each hour. That is how I see the current draft now.

[roeycohen]

Hi (new the conversation)...

If i understand correctly, one of the main concern with giving the developers the option to launch the install process, is that spammers will spam the users home pages (users will accidentally will approve the install process). Maybe a solution for that can be a process that behaves more like other applications installation process. When the user clicks the install button, the browser will display an install message on the entire screen, with a short explanation on what's going to happen and wait for approval. That's almost the same process of clicking a button that sends the user to the store application.

Bottom line is that the current behavior is just not acceptable. end users are not familiar with "web apps", most of them probably not even aware of the "add to home screen" option. Not being to register the applications on stores is already a huge drawback, so hiding the option to install the application when needed i just making things worse.

[roeycohen]

@slightlyoff i understand your position, but there's a real problem here, and the current solution isn't good enough. please try thinking out of the box, for people who want to create legit applications and install flow.

Personally, I think we should leave to website vendors to design their websites the way they want with as many install app buttons as they want. It's how it works for any other app and shouldn't be different for wpa.

[photopea]

Folks, so I think that every website should have a chance to "be installed" (if the visitor and the author wish to do so).

Currently, you tell browsers to trigger "onbeforeinstallprompt" whenever they find it appropriate. But then, authors would have to test their apps in all existing browsers. Some browsers are not for free (e.g. you need to buy Windows 10 to use Edge, or buy an Apple device to use Safari).

Why don't you aim for the web to be defined precisely, and to work the same way everywhere? I suggest, that you should make it mandatory for every browser to trigger "onbeforeinstallprompt" on every website the user ever opens. What do you think?

I just spent 3 hours figuring out why "onbeforeinstallprompt" is not triggered for my website in Chrome. I had to use special tools such as Google Lighthouse, and I still haven't figured it out. I really don't want to spend 3 more hours to investigate the same problem for each other browser.

[aeallord]

"I think that every website should have a chance to be installed". I for one need to disagree with this statement. Should this be the case then we will soon have the annoying "install me" prompt/button or whatever as we currently have with every website wanting to use a visitors location. Currently programmers rely solely on the browser to block it without consideration of the end user.

[photopea]

@aeallord Currently, the browser shows the Install banner by itself, whenever it thinks the website is "appropriate for installing" (even if neither a website, neither a visitor want such behaviour).

Browsers could have a switch "Forbid Location / Installing for all websites". I believe, that the recent wave of requesting a visitor location, was just a misjudgement of creators, which got too excited about the new feature. It never lasts longer than just a couple of weeks.

[mgiuca]

I don't think at this time we're going to be providing a more aggressive API for sites requesting install, beyond what BIP does. Since we're planning to move BIP from the spec (on the grounds that it is not being implemented in other browsers, due to already being too aggressive with how much control it offers sites), I think it's time to close this out.

Chrome and other Chromium-based browsers will continue to support BIP, but we won't be taking this suggestion.

[Trapfether]

What if instead of providing a javascript API to prompt the user. The UA can provide a function that allows Authors to provide an element that when clicked, should act as if the user went through whatever manual process the UA already implements (clicking the ambient badge in firefox, opening share and tapping "Add to Homescreen" for ios). I think that individuals are over complicating the request here. Give web authors a way of providing a button that allows a user to easily trigger the installation prompt.

ex. navigator.registerInstallationButton( myInstallationButton );

The aversion to allowing some "Install" button within the web content area is not discouraging the bad actor behavior of spamming install buttons as some have expressed concern over. Bad actors are already making this a reality, but with using UA specific dialogs and modals to walk consumers through how to install the apps. The absence of some means of triggering the start of an install flow does nothing but create extra work for legit authors, confusion and aggravation for users who "Just Want To Save This To My Homescreen, Why Is This So Difficult?". As an author for several of these experiences, I have had to personally walk consumers through the process when they couldn't figure it out and decided to CALL ME. I have legitimate users who want this feature bad enough to pick up a phone and call support. If that doesn't point to the necessity of some means by which a Author can provide a "Click Here To Save This To Your Homescreen For Later Use" style button, I don't know what will.

(as an aside, the situation is exasperated with IOS devices where I must walk consumers through how to context switch into safari, then the user has to hit install AGAIN in order to be shown the instructions for how to add. Not a dig on apple, just a context specific observation relevant to the discussion at hand)

[photopea]

There exists a "Pointer lock api", which allows a website to "lock" the mouse at a specific coordinate (and the user can not move it). It is not hiding the cursor with CSS (when you can see the cursor if you move the invisible cursor out of the website). It is just like it sounds - the cursor is locked and can not be moved.

For some reason, this API exists for over 10 years and we do not see cases of websites "abusing" it. To me, the Pointer Lock API looks much more "abusable" than the install prompt API. So I don't see a reason why the site can initiate the pointer lock, but it can not initiate the install prompt.

[mgiuca]

The difference between the pointer lock and the install prompt APIs is that the latter can be used to establish a permanent presence on the user's machine, whereas a pointer lock (while annoying), doesn't have any long-term side effects once the user escapes out of it (and, on Chrome at least, we show UI to tell the user how to get out of it).

To be clear, the reason we regulate access to the install prompt is less to do with the modality of the dialog, but the consequence to the user if they just accept it without thinking. (Note: Installation generally doesn't grant extra permissions, but it does put the app on the user's system, which provides future opportunities for spoofing as it will be launched without browser UI.)

A closer analogy is the notifications permission, which also establishes a permanent presence on the user's machine. And that certainly is being abused, in large numbers.

[Trapfether]

To be clear, the reason we regulate access to the install prompt is less to do with the modality of the dialog, but the consequence to the user if they just accept it without thinking. (Note: Installation generally doesn't grant extra permissions, but it does put the app on the user's system, which provides future opportunities for spoofing as it will be launched without browser UI.)

If the user downloads a file without thinking, bad things can happen, or open an email, or any other number of things that the web exposes users to every day, many of which can establish permanent presence on various devices. As I've brought up before, the absence of a means for a web author to allow a user to easily trigger the installation flow does not stop bad actors from just creating the same installation dialogs every other PWA is shipping to teach their users how to install them. Requiring one of a specific set of User Gestures (specifically a click, tap, or the accessible alternatives) will cut the accidental installation ramifications drastically since sites won't be able to just show a prompt whenever they feel like it. Other possible solutions also exist, a new html element with limited styling options to avoid tricking the user that is purpose built to serve this function (triggering the installation path for the user, just as if they had manually hit the contextual icon the UA provides). Or providing a javascript API that allows a web author to register an element AS an instillation button. It is possible to give web authors the tools to make the installation process simple for their users without giving them the ability to just fire off a prompt whenever they want.

[priyansharma]

Please Help, I want to fire "beforeinstallprompt" event before caching Or just after service worker register. At present my custom button taking time to load it's load after when caching is done.