A partial archive of discourse.wicg.io as of Saturday February 24, 2024.

Require user gesture for notification permission request


I’ve noticed some websites ask for permission to send notifications immediately on the first visit. This is annoying[1], enough that guides appear showing how to turn them off [2]. It’s also surprising that these days a website often cannot even start autoplaying media upon visiting a page - to avoid annoying users - but it can still ask for you to permanently allow the website to send you notifications at any time, which is a good channel for spam.

I can’t think of any good reason someone would click “Allow” for notifications right away, without knowing anything about the website, the kind of content it will send, and the frequency. The user has likely not even clicked or touched inside the page yet. Nobody can make a good decision at this point. It seems websites are relying on users making bad decisions: hopefully some people will click “Allow” by accident, and then the website can spam them.

Why not require a user gesture? It would block this dark pattern entirely and still allow legitimate sites to work. It seems likely to improve the user experience since even if a website shows a prompt with a button to enable notifications right away, they’d probably at least try to explain why it’s useful to do so. I suspect many sites would instead relegate the option to a less intrusive UI.

[1] https://twitter.com/MattWilcox/status/910776534524448768

[2] https://www.howtogeek.com/288946/how-to-stop-websites-from-asking-to-show-notifications/


Filed a spec bug here: https://github.com/whatwg/notifications/issues/108


I’ve proposed this a year ago on the forum for Chrome interventions. Here’s the response from Chrome team:

The permissions team agrees that onload permission requests are incredibly irritating and shouldn’t be done. We also strongly feel that such requests should be made in context.

We’ve been looking into a number of things to try and discourage onload requests. Unfortunately, detecting if a permission request is made on page load (or very soon after page load) is pretty tricky to do accurately. Like Ojan said, any change we make could also break interop (Chrome won’t let you call geolocation/notifications/etc. when others browsers will).

We’ve reached out to various sites which use onload prompts to try and encourage them to not do that. A lot of these sites have basically ignored us, e.g. Facebook, which hits you with a door-slam black background page with a permission request after you login (see attached). They’ve basically said, “this works best for us wrt CTR” when we tried to tell them not to do this. This is an outlier case, but it’s representative of the attitude we’ve often encountered.

There are also sites which genuinely won’t work properly without a permission grant as early as possible (weather sites, map sites, etc.). In these cases, we don’t necessarily want want to prevent a prompt, because it will only confuse typical users who might not understand why the site isn’t working properly.

We have early metrics suggesting that permission requests are 3-4x more likely to be granted by users if they are accompanied by a user gesture - i.e. that they’re (probably) triggered by the user explicitly clicking on something on the page and directly showing interest in a feature which requires permission. We’re probably going to try an experiment where requests for permission without a gesture are simply ignored (and maybe even work to get that codified in the spec).

So yes, in summary, we know onload prompts are annoying. We’re working on solutions to try and address the situation, but it’s a challenging problem for a bunch of reasons.


I don’t think other permission prompts need to be changed. I can see that something like a geolocation request upon loading a map makes sense. It’s specifically for the notifications permission only, since I don’t think there’s a use case for displaying that immediately. I think a site like Facebook is an exception, because everyone already knows what Facebook is and what its notifications are likely to involve. But we shouldn’t make special rules for specific sites. In general, visiting a site should not be able to prompt you immediately, and Facebook should play by those same rules as well.

It should also be easy to impose the user-gesture requirement, since many other APIs are already behind that; I don’t understand why they talk about detecting a request on page load being “pretty tricky”. Also obviously asking websites nicely is not going to work and is never going to scale to the whole web, I don’t know why they even tried.

So I don’t understand that reply. I still cannot see any reasons why the notification permission request shouldn’t require a user gesture.


IMO, this is best done with a UI icon indicating that notifications are available. In such a case, the feature remains discoverable, but there are never prompts unless the user requests one.


I’ve always thought that unblocking notification permission requests (that I’ve previously blocked) or re-enabling them (after having denied them) pretty difficult for an average browser user to do. The option is buried deep into the browser settings–at least on Chrome. People also are likely to forget that the feature was even available (after having previously denied notification permission requests). That said, I’m in favor of an icon. I would also go as far as making the icon clickable, which would give a user quick access to manipulate any notification settings.


That’s a good idea actually. Outside a user gesture it could quietly create a toolbar icon, like blocked popups in Chrome. The user can still click on it and allow if that’s what they want.


See also this related discussion:


  • There are some cases where asking to receive notifications on page load offers a good user experience: for example after login, or when you enter a chat
  • Sometimes you try to get the push subscription (calling pushManager.subscribe) on page load just to send it to server with some new tags or data and the browsers should not break this (you don’t even display a prompt to the user)
  • If you completely block the prompt on page load, many websites will start using horrible hacks that are even worse: e.g. detecting any gesture; display two step prompts; or display floating widgets that are really annoying. Also note that whereas the browser prompt can be only displayed once, a custom prompt (2 step) will be displayed many times…
  • I agree that displaying a small icon on page load can be a good compromise that doesn’t break the existing API and would improve the UX

The 2-step prompt has been done, sadly. Someone created a JS library which shows a fake notification prompt emulating the native Google Chrome prompt, and I’ve seen it several times. (By the way, if you are worried about it, enable dark mode. It uses light mode. )


Good point! Is it possible limit the notification prompt to users who have installed the website as a PWA? Or are PWAs no longer a thing? :smile: