New issue
Advanced search Search tips
Note: Color blocks (like or ) mean that a user may not be available. Tooltip shows the reason.

Issue 274284 link

Starred by 44 users

Issue metadata

Status: Fixed
Closed: May 2014
EstimatedDays: ----
NextAction: ----
OS: All
Pri: 3
Type: Feature

Sign in to add a comment

Notification.requestPermission cannot be called on load events

Reported by, Aug 16 2013

Issue description

UserAgent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_6_8) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/31.0.1601.0 Safari/537.36

Example URL:

Steps to reproduce the problem:
Open the attach test case

What is the expected behavior?
The notification permission prompt should be displayed to the user.

What went wrong?
The notification permission is not displayed.

Does it occur on multiple sites: N/A

Is it a problem with a plugin? No 

Did this work before? N/A 

Does this work in other browsers? Yes Firefox 22

Chrome version: 31.0.1601.0  Channel: canary
OS Version: OS X 10.6.8
Flash Version: Shockwave Flash 11.8 r800
270 bytes View Download

Comment 1 by, Aug 19 2013

Labels: Cr-Blink Cr-UI-Notifications
Labels: -Type-Compat Type-Bug

Comment 3 by, Oct 10 2013

I can confirm this issue. Not being able to ask for notifications at the load of an app is kind of a bugger. Is there any way besides in a "click" handler to ask for permission?
Labels: -Pri-2 -Type-Bug Pri-3 Type-Feature
Status: Available
Chrome requires that permission be requested only in response to a user action.  Unfortunately this typically means a click.  I will leave this bug open as a feature request (especially since the w3c notifications spec does not require this behavior) but we are unlikely to change it at this time.  Consider writing a Chrome app if you would like access to notifications without prompting the user (except at install time).

Comment 5 by, Oct 10 2013

Except you're already asking the user, though. Why require *two* user interactions in order to make this happen? It's absolutely ridiculous to only allow the user to be asked if they just triggered an event. It's a useless requirement that provides little benefit to the user.

Comment 6 by Deleted ...@, Oct 28 2013

Especially annoying because I'm requesting this from inside a Unity Web Player app- how do you suggest requesting notification permission from inside a non javascript application that handles its input without javascript input handlers?

Comment 7 by, Oct 29 2013

Somas, can you provide more background on why the user action was required?
Another point - If I initially grant permission through a click handler as required, but in a subsequent app incarnation, I already have permission, I need to call Notification.requestPermission() to determine whether I already have permission.

Chrome therefore is requiring a user click to determine that permission was already granted!!!

Please either change this behaviour, or implement the Notification.permission attribute so that existing permission can be determined without first calling this method.

Following the above update, it would appear that Chrome allows webkitNotifications.checkPermission() instead of Notification.permission.

A workaround for some people perhaps.

Please fix this issue as its very bad experience for a user to click on some thing to get permission prompt again & again.
As of Chrome 33 Chrome now uses Notification.permission.
This behaviour is causing notification to fail on callbacks, even if the callback originates from logic with a click event. e.g. The user clicks a button which calls a function. The function calls something with a callback and puts the notification event in the callback so that the user is notified when the action is done. Chrome does not see the notification in the callback as originating from the click event.
Could you >>>PLEASE<<< enable some kind of checkbox in Settings that turns debug console messages ON for when your policies are trying to waste my entire life away chasing nothing on my end? When you know you're deviating from/violating a documented public standard, either (a) don't *do* that; or (b) log something like to the console. I recommend something like:

STANDARDS DEVIATION/VIOLATION: Notification.requestPermission can only be called in response to user input.

That would save developers a lot of f*****g a**h***s.

W3C Last Call Working Draft 12 September 2013

"In designing the platform[,] notifications are the one instance thus far where asking the user upfront makes sense. Specifications for other APIs should not use this pattern and instead employ one of the many more suitable alternatives."

MY CHOSEN RESULT: The Notification API is a standard. As such, I am electing to not support it in Chrome until the published standard changes or Chrome does. In the interim, the language used in THE SETTINGS VIEW of my app (on Chrome) will simply be:

"Google Chrome does not yet adhere to the Notification API standard. If you would like to enjoy desktop notifications while [app name] is minimized, please use a browser other than Google Chrome. If you would like to encourage Google to adhere to industry standards, please consider starring this bug on Google Code: [link]."

...with a link to this bug.
Labels: Cr-Security-UX

Comment 15 by, Apr 22 2014

Re #13: Please keep it civil. We don't design our features based on who insults us the most. To be clear, you could wait for the very first click on the page and then show the dialog, which would be more or less the same effect.

gbillock: My understanding is that page bubbles will allow request either on load or on user gesture. Is that right? (Will that fix these complaints?) I thought it would but the test case doesn't seem to work even with the page bubble flag on in Canary.

Comment 16 by, Apr 22 2014

Labels: -OS-Mac OS-All
#13: We await your apology.

Everyone else: This is OS-All, right? Not just Mac?

I can't get the repro case to work at all, is that expected? I tried with both 

  9     Notification.requestPermission();
 10     webkitNotifications.checkPermission();

Comment 17 by, Apr 22 2014

Please don't feed the trolls, and thank you for looking at this.  (More people than he have star'd this issue)
Here is the minimum working proof of concept, btw:

  1 <script>
  2 window.addEventListener('click', function () {
  3     Notification.requestPermission();
  4 });
  5 </script>

So, it doesn't seem very hard to get a working notifications system on a web app. (Note onclick instead of onload.)

Most real applications will involve a user gesture, right? Can anyone point to a real application that can only work if the permission request fires onload?
@16 It is on all platforms, or was. 
Also, it's not just onload. It'd be nice to ask for notification permissions when it's needed. For example, you have a chat application and an incoming message is sent and you'd like to show a notification. Too bad you can't ask for that permission until the user clicks on something.

That's the biggest use case for allowing notification permissions not only in event handlers, IMO. You can react to events besides the user clicking things and ask for permissions then.

Comment 21 Deleted

Shall we split this into two feature requests?

* Notify in the console when requestPermission is called outside of a user action event handler so developers at least know what's going on

* Consider removing the user action requirement since it isn't really a common restriction among other browsers, is not mentioned in the spec (though not explicitly disallowed) and impacts usability overall (which already is pretty bad since infobars are easily ignorable, separate from the site's UI, etc..)

Comment 23 by, Apr 22 2014

I've deleted comment #21 because it goes way over the line in terms of obscenity and threats of violence. Please re-post your comment if you want to keep having a real discussion about this.

Comment 24 by, Apr 22 2014

Re #22: That's a good idea. I've filed  for the console issue.
For the record: geolocation, storage, downloading multiple files (and I believe getUserMedia) don't require a user gesture either. These should be consistent, we either require a gesture or not, and I feel that changing the behavior for geolocation might break sites.
I think requiring a user gesture might have been a bit of a premature optimizations and we should just revert this until further steps are decided wrt the standard

Comment 27 by, Apr 22 2014

dewittj@ do you know the backstory for why a user gesture requirement was added here?

Either way: I'd like to keep the user gesture requirement for off-origin iframes (jochen@ this is what my email question was about).
Darin suggested this in the initial codereview.

Can't we bring the off-origin case to the standards first?

Comment 29 by, Apr 22 2014

Yeah, I would want to bring up the off-origin iframe case to the standard. But if we make it *start* working then there will be a cost to later removing it, whereas if we never start supporting it in the first place then we don't have to worry about deprecating.
meh, I think that's a rather weak argument for deviating from the standard.
I can provide some backstory as to the user gesture requirement (see also: there was significant concern when we originally proposed the webkitNotification API to webkit-dev that people would use this API to spam users with permission prompts and trick them into enabling notifications, which could then be used to display annoying ads, phishing attempts, etc, since notifications bypass popup blockers, work from background tabs, etc. The cost of a mis-granted permission is  higher for notifications than it is for something like storage or multiple file download.

So only allowing this permission request in the context of a user gesture was our attempt to prevent this (and was, frankly, the only way we got the feature launched originally - believe it or not, at one point it was viewed as fairly controversial). It also is an attempt to guide developers towards pushing their users through some kind of reasonable UX flow when enabling notifications, instead of just spamming them with a permission prompt with no context as soon as they hit the website.

#20: I would argue that in the case you cite (displaying chat notifications) you absolutely do *not* want to wait until a chat comes in to display the permission prompt - because at that point the user may have already switched tabs and now your permission prompt will be displayed on a non-visible tab. A much better UX is to prompt the user up front in your UI if they would like to configure notifications (possibly even giving them some options for which events should trigger a notification), and a permission grant could be part of that flow.

Anyhow, I'm not strictly opposed to removing the user gesture check if that's what other browsers are doing (I haven't confirmed whether this is the case), but it will have implications for user security (it makes the API easier to abuse, which means we'll have more users who unintentionally enable notifications and more unscrupulous website authors trying to find ways to serve ads and phishing attempts through notifications) and I haven't heard a compelling argument for why it's better for users for websites not to have to build some kind of user-gesture-based flow for enabling notifications.

The end result of removing the user-gesture check is a world where visiting results in an unprompted request to grant notifications permission to, and it's not clear to me that this has any user benefit, although I understand why web developers don't want the hassle of building an elaborate permission grant UX flow.
For permissions bubbles, I have not currently modified any existing policy with when the requests are permitted. Different APIs may have different policies as to when they ask for a bubble, but the permission bubble policy is intended to be that a request can succeed on page-load and otherwise on user gesture.

(That's the current state of the design doc policy; this may end up evolving depending on whether there's abuse.)
@drew, it's a pity we didn't update the standard back then. Anyway, for geolocation, we don't block on a user gesture, and we don't see random requests all over the web either.

@greg, I hope you'll work with the resp. standard bodies to update the standards first before changing the behavior.

Comment 34 by, Apr 23 2014

re #33: geolocation is not a good model. people only grant geolocation 7% of the time it's requested which makes it seem like most geolocation prompts are in fact pretty spammy.

anyways I am planning to go to standard bodies about iframes.
@jochen, I don't anticipate changing any behavior -- that's up to people implementing calls to the bubble system.

That said, I don't know that I agree that there's much traction in addressing this in standards language uniformly. Similarly to popups, these kinds of calls are going to make the browser bring up a new UI surface, so we're going to be correspondingly protective of that ability.
@jochen - IIRC, at one point the user gesture thing was in the notifications standard, but it was ultimately removed because browser developers didn't have consensus around it.

Re: geolocation: I would say that the utility of notifications for spamming and phishing is higher than that of geolocation (in general, you can get pretty solid geolocation results just doing server-side IP->Geo mapping so it's not clear why you'd rely on the user clicking a geolocation prompt). Also, that 7% grant rate is pretty low - I wonder what the grant rate is for the current notifications prompt?

Comment 37 by, May 7 2014

Another vote in favor of removing the user gesture requirement here. Here's my use case:

I'm adding notification support to a chat client that runs as an iframed widget inside a host page. For various reasons it is best to delegate the notification permission requests and notification rendering to the host page, and the client notifies the host page to render new notifications via postMessage. However, the UI to enable notifications is inside the chat iframe itself, so it's not possible to request permissions directly in response to a user gesture, as the request first has to travel to the host page.

One solution would be for the user gesture bit to travel with postMessage, but that's probably a big project. Just removing the user gesture requirement here seems relatively benign - is the possibility for abuse really so large? AFAIK Firefox doesn't impose this limitation for the notifications API.
BTW, it would be nice for user gestures to travel with postMessage() the same way they do with timers, with the same time restrictions. I actually don't think that's much work - you should file a bug for this because the two cases (timers vs postMessage) should react the same wrt user gestures.
they do

Comment 40 by, May 12 2014

Looks like I spoke to soon, the gesture bit does travel with postMessage, and there was a flaw with my implementation. So my issue is mostly solved, though it definitely still would be helpful the the user gesture requirement to be dropped.
Project Member

Comment 41 by, May 15 2014

The following revision refers to this bug:

commit cde1514cc7d93e84c926a85672152747d4efa293
Author: <>
Date: Thu May 15 06:47:33 2014

Drop non-standard user gesture requirement from notification.requestPermission

BUG= 274284,,

Review URL:

git-svn-id: svn:// 0039d316-1c4b-4281-b951-d872f2087c98

Labels: M-37
Status: Fixed
Hello everyone. If I have understood correctly the whole conversation, Notification.requestPermission should not require any user direct action, e.g., 'click', to be prompted.
I am running Chrome Version 36.0.1985.125 m and I still need to do bind the Notification.requestPermission() method to window.onclick, as suggested in #18, as it would not work otherwise.
I would like to know if I have misinterpreted this bug history, this fix is not merged to Chrome yet or any other scenario. 

I hope I made myself clear, apologies if I have misunderstood anything.
This is fixed in Chrome 37. It does not seem to work in Chrome 36.0.1985.103, but I've verified it works in Chrome 38, at least. Please try with Chrome 37 (current beta channel) and respond here if it doesn't work.
#45, atwilson, thank you for the quick reply. I do confirm this works in Chrome 37 (Windows 7 build).
Components: -Security>UX
Labels: Team-Security-UX
Security>UX component is deprecated in favor of the Team-Security-UX label

Sign in to add a comment