Allowing only site-triggered install prompt

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.

Yeah, we've gone back an forth for years between the current model and the .install() model. The problem with the .install() model is that we will end up with "Install my App!" buttons all over the web, which we don't want.

Browser vendors are exploring alternatives (e.g., ambient badging)... there might be a middle ground for this, but we are still trying to figure out what it is as PWAs become a thing.

So you want give browsers the ability to limit such buttons with "Install my App"? The button would be hidden. And neither the website, neither the user would understand why.

I think your should not be afraid of such buttons "all over the web". Websites always adapt to users, and when e.g. less than 1% of users use such button on a specific website, it will disappear (or will be moved to some less visible place), because the space on the website is "expensive". It would be like having an add, which is not clicked by anybody (nobody wants such ad). So I believe, that at the end of the day, Install buttons would be only at places where it makes sense.

And even if you still want to have power to limit such buttons, giving this power to the browser and probably any other solution could make users very angry , and is a huge space for corruption (a black box oracle, which decides things for us).

@mgiuca

Google is toying with a new way of doing this.

Ie. they might stop prompting by default when the engagement threshold is triggered, but allow the site to do it after that point.

@mgiuca might be able to tell more.

I would like to let my users start my webapp from a home screen icon and without the browser controls around it. When will it be possible in a Chrome browser?

You should be able to set display: 'fullscreen': https://www.w3.org/TR/appmanifest/#display-member

But how can my users add the icon of my webapp to the homescreen? Can I create "Add to homescreen" button in my webapp somehow?

@photopea

Firefox pattern seems good to me (a add to homescreen icon directly in the address bar and a android icon if the webapp is already installed). Chrome should provide the same kind of UX on every platform because on desktop, the add to desktop is a hidden features, hard to explain to the end user.

Install my webapp! buttons are a "risk" like enable push notification/geolocation! is one too. It's not necessarily a bad thing, it just needs some guidelines.
There are already download for mac/linux/window buttons for installables software. There are already android app on google play and available on the appstore buttons for native app. Why a Install the webapp icon can't stand near these last for a single point of "get my product"?
Today, it's easier to wrap a webapp url in a electron app which can be downloaded in one click rather than explain to the end user how to add the webapp to desktop.

it's ok if it's on the browser side, people trust browser more than websites. Webapp installation could be triggered like any others permissions, instead of an auto prompt with obscur rules which differ from a browser to another.
Yes, it can be misused, like any other things on the internet (permission prompt on page load, i'm looking at you) but browsers should not concentrate on "what is the best moment to prompt the user to maximize their engagement", it's a developer's concern.

@photopea you can't, browsers decide when it is the appropriate time to show the prompt and provide a way to do it manually (three dots > add to homescreen on Chrome Android, three dots > more tools > add to desktop on Chrome desktop, add to homescreen icon in address bar on Firefox Android)

That is quite bad. I think webpages should have the ability to trigger the "installation" to a desktop. What kind of misuse do you mean? It is not a real installation, but more like a bookmark. It is till safe, "sandboxed" in a browser environment.

I implemented the current "way" to my webapp in the past, but it was hard to explain to users, that they have to wait until their browser "feels like" they may want an installation. And if they accidentally refused the installation, there was no way to trigger it again, it did not work even the next day. The rules are not clear, what does "the browser feels like" mean? (it was Chrome in my case)

@photopea

@photopea, we understand your frustration - but please understand that it will take time to figure out the right solution here.

We (browser makers, developers, and End-users) know that we don't want "INSTALL MY FANCY APP" buttons all over the Web - but we also know that developers want user's to be able to easily install their web applications. We also know that we have all these "browser feels like" heuristics, that we can make use of... we just need to put them all together in a way that balances everything out.

The above will still take time to figure out, however. If we move too fast, we risk screwing things pretty seriously on the Web. We need to be disciplined in how we add these kinds of features.

@photopea

@photopea, in case it helps, it might be good to read how we assume it works at the moment:
https://www.w3.org/TR/appmanifest/#installable-web-applications

See in particular, the part about installability signals. Hope that helps you understand where we are at.

@marcoscaceres

@marcoscaceres I see where the specification is at the moment. I think there are two key points, where I see problems.

User agent should not be the "robot", who decides things for us. Decisions should be made either by user, or by a program developer. I can see of browsers becoming 20% larger (in terms of MB), because they will embed some AI libraries, to be able to claim, that their decissions are better than the decissions of other browsers. If you want to guarantee some level of "security", make strict rules (e.g. HTTPS + manifest + something else), that will work for all browsers. Don't make it up to browsers to decide. Web authors would have to test their product with many borwsers to make sure it works everywhere. We are getting the web back to 90s.
"INSTALL APP" buttons all around a web is nonsense. The area of the webpage is "expensive", and when some button is not clicked, it is replaced by something else. Such buttons can be everywhere only for a couple of months, until authors see how effective they are, and most of them would remove these buttons. Just like we have Social media buttons now.

Please, think about it. Don't make browsers take decissions without specific rules. It may add a lot of headache to both web authors and visitors.

@photopea

@photopea, thanks. Will definitely take your feedback into consideration.

@photopea

Hi, sorry I've missed this discussion until today. This is something I think about all the time.

I do mostly agree with @photopea and I think the Google Chrome team has been gradually coming around to the position that developers should be in control of this, not the UA. We've gone from a relatively unpredictable engagement requirement (requiring heavy use of the site before the prompt can trigger) to an almost instantaneous one: we now deliver the BIP event after a few seconds of interactivity with a site. This means if the user immediately closes a site, they won't see it, but any normal usage will be able to show the prompt.

We should recognise two separate issues:

the static issue of which sites are eligible (manifest, correct icon size, fetch handler, etc, etc), and
the dynamic issue of under what circumstances do we allow the prompt (after the user has engaged with the site by a certain amount).

I am not concerned about the dynamic issue, because it doesn't present a compatibility risk. Different browsers can have different dynamic (engagement) requirements, and it doesn't "break" sites because the developer doesn't need to design differently. You just need to know that you may need to wait awhile before the prompt event comes up.

I am concerned about the static issue. I think it's a web compat problem if different user agents have different requirements for a site to be eligible to receive a prompt, because then, as you say, we're in the 90s world where developers need to test that they meet the criteria for each major browser. That harms us (the browser manufacturer) too, because then we can't change our policy in the future. (Just as in the 2000s, IE was ultimately harmed by being tied to its own de facto standards.)

User agent should not be the "robot", who decides things for us.

In some sense. The UA will always play a role in deciding things on behalf of the user. After all, they are the user agent (authorized by the user to act on their behalf in making certain decisions). That's why I am OK with requiring a minimum engagement, and with having a browser-specific policy on when you can re-show a prompt if it has been rejected by the user. As well as, of course, UA-specific UI for manually installing the site without a site-triggered prompt.

What's weird about this is that we allow sites to spam notification permission requests immediately (which arguably is requesting a more invasive capability than installation), but we're more conservative with showing the install prompt. I think we should be more consistent about this.

Web authors would have to test their product with many borwsers to make sure it works everywhere. We are getting the web back to 90s.

Yep, I definitely share this concern, as stated above.

Chrome has tried to make the "whether or not you are a PWA" check as transparent as possible, publishing the checklist and providing a tool to verify whether your site is eligible. But up until now, this has been a proprietary Chrome feature.

I definitely think we'll want to lock this in at the specification level at some point, so the Lighthouse tool can tell you definitively whether your site meets the specified requirement for installability in all browsers. However, I think at the moment we're still early on in the life cycle of this feature, and people are worried if we codify this, we won't be able to increase the requirements later (e.g., by enforcing that your fetch handler actually serves content).

Different browsers can have different dynamic (engagement) requirements

I don't agree, you will end up with the following on every website:

you should be prompted for installation automatically but: 
- if you are a X user: wait 5s
- if you are a Y user: click somewhere
- if you are a Z user: visit the site twice

edit: I mean automatic engagement is fine if the developer can prevent it

What's weird about this is that we allow sites to spam notification permission requests immediately (which arguably is requesting a more invasive capability than installation), but we're more conservative with showing the install prompt. I think we should be more consistent about this.

Definitely. And educate developers is the way to go. Today, it's obvious that ask for a permission without context will lead to high rate of "block".
It is not the UA role to show a prompt when it decides to. It's like automatically ask for geolocation permission if the GPS is active on the terminal.
There is a requirement -> UA check the requirement -> requirement is satisfied -> UA allow the developer to prompt the enduser -> developer ask UA to prompt the user at the right time in his context

I think at the moment we're still early on in the life cycle of this feature, and people are worried if we codify this, we won't be able to increase the requirements later

Agree, but we are already in the "later" part
Edge made a move with auto index PWA in the store depending of their own quality criteria and Chrome already gives guidelines in lighthouse.
Edge considers service worker as an ehancement when it's big warning in lighthouse if it's missing.

check "quality signal of progressive webapp" part https://blogs.windows.com/msedgedev/2018/02/06/welcoming-progressive-web-apps-edge-windows-10/

We're keenly aware of the difference between web and native here, and are working to reduce those differences. However, we also want to ensure that the significant structural and security advantages of the web over native apps is not lost. Add to home screen should be an incremental improvement over the existing functionality of a web site. You should be able to use and derive value from the web without having to install - that's a huge advantage over native in a world where billions are users are data-constrained and are adverse to having to download a large artefact. Add to home screen is an added bonus, not a necessary requirement.

The right to add to home screen is significantly more powerful than either fullscreen or pointer lock, since it actually leaves a permanent artefact on the user's device that can be persistently re-enter an app-like context.

I suspect that initially for a few months there will be spam. After PWA's becomes the norm, things will settle down.

I don't think there would be spam.. i want to delay the add to home screen only after i am sure that the customers have a good and a meaningful interaction with my site i.e, complete a purchase or added some items to wishlist...prompting them too early will definitely get lots of rejections... that's why i feel that its better if the control is with the developers.... and not the user-agent...

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.

@slightlyoff

@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.

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.

"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.

@aeallord

@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.

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.

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)

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.

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.

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.

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.

Navigation Menu

Repository navigation

Allowing only site-triggered install prompt #627

32 remaining items

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Allowing only site-triggered install prompt #627

Description

Activity

marcoscaceres commented on Nov 14, 2017

photopea commented on Nov 14, 2017

kenchris commented on Nov 14, 2017

photopea commented on Feb 22, 2018

marcoscaceres commented on Feb 23, 2018

photopea commented on Feb 23, 2018

madmoizo commented on Feb 23, 2018

photopea commented on Feb 23, 2018

photopea commented on Feb 23, 2018

marcoscaceres commented on Feb 26, 2018

marcoscaceres commented on Feb 26, 2018

photopea commented on Feb 26, 2018

marcoscaceres commented on Feb 27, 2018

mgiuca commented on Feb 28, 2018

madmoizo commented on Feb 28, 2018

32 remaining items

dominickng commented on Jun 4, 2018

anirbansaha77 commented on Jun 11, 2018

roeycohen commented on Aug 12, 2018

roeycohen commented on Aug 13, 2018

photopea commented on Sep 8, 2018

aeallord commented on Feb 6, 2019

photopea commented on Feb 6, 2019

mgiuca commented on Apr 1, 2020

Trapfether commented on Sep 15, 2020

photopea commented on Sep 15, 2020

mgiuca commented on Sep 16, 2020

Trapfether commented on Sep 16, 2020

priyansharma commented on Jul 15, 2022

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions