-
Notifications
You must be signed in to change notification settings - Fork 160
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Allowing only site-triggered install prompt #627
Comments
Yeah, we've gone back an forth for years between the current model and the 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). |
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 |
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? |
Firefox pattern seems good to me (a
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. @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, 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, in case it helps, it might be good to read how we assume it works at the moment: See in particular, the part about installability signals. Hope that helps you understand where we are at. |
@marcoscaceres I see where the specification is at the moment. I think there are two key points, where I see problems.
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, thanks. Will definitely take your feedback into consideration. |
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:
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.)
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.
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). |
I don't agree, you will end up with the following on every website:
edit: I mean automatic engagement is fine if the developer can prevent it
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".
Agree, but we are already in the "later" part check "quality signal of progressive webapp" part https://blogs.windows.com/msedgedev/2018/02/06/welcoming-progressive-web-apps-edge-windows-10/ |
Guys, I am horrified by your calling installation as "spamming". I can't see what would be more spamming in window.install() than in window.alert() ? Both would "pause" the webpage and require the user to interract, to be able to return back to the site. Why we are not limiting the alert() in any way (e.g. the website would have to get a "permission" to alert)? Why we don't see 90% of webpages alerting messages right after you visit them? I think your idea of the effect of allowing "simple install" is absolutely misleading. What makes you think any website would want to fire install() at the user right after he visits it? That would be like a shop owner shouting at you right after you enter a shop. You would probably never go back to that shop. What you are suggesting is forbidding the shop owner to say a singe word during the first 10 minutes in the shop. So even if both the customer and the shop owner want to say something to each other, you are forbidding them to do so. I am really shocked that you can not see it and I have to explain it to you in these terms. |
We do limit it. The browser only allows you to call it a few times at certain rate - then asks the user if they want to stop it from showing alerts.
With all due respect, we’ve been at this a few years (~5 now). I’d encourage you to search through the closed issues around installation, install prompts, and install buttons. We’ve done extensive research into this problem and will still take a while to work out. It’s not as trivial as you make it sound. |
The browsers may choose if they want to provide an option for restricting "Alert" calls by the webpage. So you do not limit it, but some browsers do. But you want to limit the installation "by design", directly in the standard specification. That is a completely different thing. Imagine, if each website had to go througn a complex process to obtain some permissions to call "alert". Web standards would be so much more complicated. I have already seen many reasons in this thread, which I think summarize your thinking about this issue over the past. In general, I think you underestimate the power of "natural mechanisms". When a webpage is abusive in any way, visitors go away. No author wants his visitors to go away. So in practice, "abusive" behaviour (playing sound right after pageload, going Fullscreen without any user input, overriding the Ctrl+N shortcut) is used only when it is really needed (and when the user certainly expects it). You may think you are limiting abusive webpages from harming the user, but in fact, you are limiting all webapps from getting closer to native apps. |
Hi, I thought to share my opinion regarding this topic, I share a lot of points of @photopea. I will start with the problems and then looking for some solutions. All this points comes out when I started to integrate PWA myself, are problem I had to discuss with business and designers. Problems
Possible solutions
I hope this post helps and happy to carry on participating on this topic. Thank you for listening. |
Thanks @MatteoWebDesigner for the input. I share your concerns that there will be (or there is already) so much variance across browsers that helping uses will actually require UA sniffing (and showing help screens specifically for each to help users manage their PWA installations). To reframe the constraints which would need to be in place for
I think some "installability signals" requirements might be too onerous (e.g., MUST have a service worker, MUST be mobile capable, etc.). We could simplify it to the above. Then we just block away the @mgiuca, thoughts? |
@marcoscaceres I still can not see, how is window.install() more dangerous or intruding than windows.alert() ? Why it can not be handled in the same manner and has to have so many restrictions? Even if the user installs the app without knowing "what it means", the app will still run in a browser sandbox, without getting any extra privileges. We are just talking about the more fancy bookmark. Browsers don't forbid you to make HTTP bookmarks. |
Let’s consider the inverse: we know alert() is terrible for users, why would we want to replicate it or anything that approximates it?
As above. If we know something is harmful, why should we use it as precedent? Why would not try to come up with something that avoids legacy problems?
You === user, sure. But websites cannot make the bookmark. That’s the core distinction here. |
I agree with @marcoscaceres we should not carry on copy features which are a bad legacy we should try to make the ecosystem better. I think the restriction proposed are fair. Especially if that's allow dev to have a consistent way to trigger install, I am happy for the trade off. The iframe restriction is very good. Thank you again @marcoscaceres |
Today's situation: a broken user experience; on some devices users will see an "add" (they are afraid of using "install") prompt sometimes (based on beforeinstallprompt), on some other devices, there is no prompt. Designers are creating UA-dependant floating dialogs and screenshots or animations to show the user how to "install" the app based on the current browser and OS. Therefore, users might not understand what's going on, or how an app can be installed and we are back to techniques based on UA sniffing. I think this is a current issue for the Web App Manifest "installation". What to expect: The experience should be more consistent between platforms and let the web content offer an install button is actually the good idea. Users don't have a "store" to install these web/apps, so the UA is the store. While we can't force UAs to use a consistent UI for a native installation, we can offer web developers an API to request that behavior from a consistent UI within the boundaries of the website's canvas, if they want to. I agree that the installation dialog should only be available when some conditions are met, both from user interaction and requirements from the site. Also, following some ideas recently implemented for Web Push permission dialog, if the user rejects or dismisses the dialog, UA can remove support for the API for that origin for an amount of time to promote authors to use it with responsibility. Suggesting a non-modal dialog sounds like a good idea. I'm not sure though if the install() method should also have some optional or mandatory checks that can be made to be sure the icon/app is not already installed. It might be an optional attribute, a different interface or a different API, such as in:
|
I have seen the installation offer in mobile Firefox yesterday. The browser itself shows the install option over the whole screen, right after you visit the website. After you dismiss it, it adds the install button next to the site URL (in the browser UI, making the URL field smaller). And the site author can not do anything about it. Please, remove these automatic "self-deduced by UA" offeres from the specification completely. The "installation" should be initiated only by the visitor = site author (I think about the author and the visitor as the same side, since the goal of the author is to satisfy the visitor). I don't think the window.alert() is some legacy monster, which ruins the web experience of the whole humanity. Just because you let authors interrupt visitors, does not mean they will interrupt them all the time. You underestimate the "law of free market" - visitors avoid interrupting websites. So in the long run, the website is either visited a lot and not interrupting, or interrupting, but not visited by anybody. |
@photopea you might be able to stop that banner preventing the default behavior on "beforeinstallprompt". But I agree that a banner sounds more legit if it's opt-in, not automatic. I'm not sure about the badge in the URL field though, that seems like a valid UX from a UA point of view. If your website is installable, offering an option within the UA user interface to install that sounds good to me. |
"If your website is installable, offering an option within the UA user interface to install that sounds good to me." - I completely disagree. The page could be "buyable", so the UA would add the Buy button. Or the page could be "schedulable", so the UA would add "Schedule" button. Or the page could be "callable", so UA would add the "Call" button. UA interface would get extremely messy (or extremely large, giving less area to the site content). The behavior would vary across UAs, so the author can never be sure, how many users are going to get angry on some minority UAs. All such things should be only allowed in the website content area, so site authors have control over them. If we give UAs so many chances to improvise, we only create the space for UA users to argue with UA authors in the future decades. |
That already happened... what about bookmarking (for example, the star icon on Chrome URL bar)? Do you want browsers to stop allowing your website to be bookmarked? Same with "reader view" or similar stuff. UAs are already offering actions for your content. At least we have this spec, there is nothing available for bookmarking or 'reader mode view' unfortunately. The web app manifest defines what options do we have for how to treat "installation", so if a browser supports the spec I don't see a problem with the "install" action offering within the UA user interface. |
@photopea @firtman I also agree ambient badges could create more noise within the browser UI but I do not think they are a critical problem if we have a consistent way of installing with window.install(). I also think browser they adapt over time to have a more suitable UI experience, you can see some For instance they knew bookmark was not a feature suitable for mobile and that's why they adapt to the new mobile model. PWA is a big experiment I think is good we are learning and trying new UX but I do think if Firefox/Samsung browser will realize ambient badge is terrible idea or they can use that space for something more important I am sure they will change it. In any case the User Agent UI is something which goes beyond the spec and we cannot create rule for that, but is good we are letting know to browsers eng which are our preferences. |
Thanks everyone for your input. Good point from @firtman about being able to check if the app is already installed - it's definitely a requirement. I think we now want input from stake holders/implementers:
If we get consensus that the current UX situation is not ideal, then we can start considering adding an API based on the requirements listed thus far:
Anything I've missed? Awaiting implementer interest before continuing. |
@MatteoWebDesigner @kenchris we're still working on the details, but right now the ambient badge is deliberately decoupled from The intention is that sites like Instagram shouldn't need to show their own add to home screen UI, they should just use our The ambient badge is a lot more more intrusive than we'd like at the moment, but without it, we can't launch the new modal app install banner, which is more predictable for devs. It's a compromise we're pushing so that developers can stop working around the limitations of the existing banners. And hopefully soon it will become much less intrusive. UI is difficult... |
Maybe @adityapunjani knows and can test as he works on the Instagram PWA |
@dominickng do you have a screenshot of how the new modal looks? Using that will still show the ambient badge? |
Guys, it is nice that you let authors prevent the "Install Modal" by listening to some event, but I think there may be some authors not even aware that some browsers show such modal for their web. Again, not interrupting the visitor should be a default behaviour. Any such dialog should be initiated explicitly by the website at the moment, when the website finds it appropriate (e.g. when the visitor clicks some button). |
I don't understand why this thread continues to debate browser UI. The only thing a web standard can (or should) do with regards to privileged browser UI is to ensure that the full range of requested UI styles are possible. Beyond that, we aren't likely to ever come to full agreement and that's OK. |
@slightlyoff that's true I rised a bug so the conversation can carry on over there. https://bugs.chromium.org/p/chromium/issues/detail?id=834017. If we exclude the ambient badge discussion I think people were coming to an agreement with the need of window.install() with restrictions. |
We will continue to restrict the situations in which any install method can
be called. That's why `onbeforeinstallprompt` was invented. Replacing it
with an inferior API will only cause churn and won't change the triggering
behavior.
…On Tue, Apr 17, 2018 at 1:31 PM, Matteo ***@***.***> wrote:
@slightlyoff <https://github.com/slightlyoff> that's true I rised a bug
so the conversation can carry on over there. https://bugs.chromium.org/p/
chromium/issues/detail?id=834017. If we exclude the ambient badge
discussion I think people were coming to an agreement with the need of
window.install() with restrictions.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#627 (comment)>, or mute
the thread
<https://github.com/notifications/unsubscribe-auth/AAF8M3hxq2HWV4WU3MElD52zGQm0alEQks5tplE0gaJpZM4QbdZ9>
.
|
I propose a standard solution to the problem which solves all use cases and avoid spam.
In addition to this, the app must not be installed on the homepage already. In our case, like an android or ios app, we need to be able to let the user install our app from the landing page. If we have a native app we can directly take them there. The web should have equal requirements or similar requirements. |
How are app makers supposed to explain to the users "well ... wait 30 seconds ... now add our website to bookmarks ... almost there ... now touch twice ... few more steps ..." And the worst part is - the webpage is not being abusive, but your browser does it for your "safety" and "comfort". There are apps on stores/markets, which can be installed and used immediatelly. Why do you enjoy "handicapping" webapps (in contrast with native apps) so much? As I said before, the install prompt should be initiated only by the webpage and the user, just like the Fullscreen API and the Pointer Lock API. |
You are right. This only makes web apps inferior to native apps. Any extra click required reduces install rate. I suspect that initially for a few months there will be spam. After PWA's becomes the norm, things will settle down. |
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 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). 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. |
@slightlyoff i understand your position, but there's a real problem here, and the current solution isn't good enough. 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. |
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 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. 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. |
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. |
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.
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:
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.
The text was updated successfully, but these errors were encountered: