Upcoming notification permission changes in Firefox 72

Notifications. Can you keep count of how many websites or services prompt you daily for permission to send notifications? Can you remember the last time you were thrilled to get one?

Earlier this year we decided to reduce the amount of unsolicited notification permission prompts people receive as they move around the web using the Firefox browser. We see this as an intrinsic part of Mozilla’s commitment to putting people first when they are online.

In preparation, we ran a series of studies and experiments. We wanted to understand how to improve the user experience and reduce annoyance. In response, we’re now making some changes to the workflow for how sites ask users for permission to send them notifications. Firefox will require explicit user interaction on all notification permission prompts, starting in Firefox 72.

For the full background story, and details of our analysis and experimentation, please read Restricting Notification Permission Prompts in Firefox. Today, we want to be sure web developers are aware of the upcoming changes and share best practices for these two key scenarios:

  1. How to guide the user toward the prompt.
  2. How to acknowledge the user changing the permission.

an animation showing the browser UI where a user can click on the small permission icon that appears in the address bar.

We anticipate that some sites will be impacted by changes to the user flow. We suspect that many sites do not yet deal with the latter in their UX design. Let’s briefly walk through these two scenarios:

How to guide the user toward the prompt

Ideally, sites that want permission to notify or alert a user already guide them through this process. For example, they ask if the person would like to enable notifications for the site and offer a clickable button.

document.getElementById("notifications-button").addEventListener("click", () => {

Starting with Firefox 72, the notification permission prompt is gated behind a user gesture. We will not deliver prompts on behalf of sites that do not follow the guidance above. Firefox will instantly reject the promise returned by Notification.requestPermission() and PushManager.subscribe(). However, the user will see a small notification permission icon in the address bar.

Note that because PushManager.subscribe() requires a ServiceWorkerRegistration, Firefox will carry user-interaction flags through promises that return ServiceWorkerRegistration objects. This enables popular examples to continue to work when called from an event handler.

Firefox shows the notification permission icon after a successful prompt. The user can select this icon to make changes to the notification permission. For instance, if they decide to grant the site the permission, or change their preference to no longer receive notifications.

How to acknowledge the user changing the permission

When the user changes the notification permission through the notification permission icon, this is exposed via the Permissions API:

navigator.permissions.query({ name: "notifications" }).then(status => {
  status.onchange = () => potentiallyUpdateNotificationPermission(status.state);

We believe this improves the user experience and makes it more consistent. And allows to align the site interface with the notification permission. Please note that the code above works in earlier versions of Firefox as well. However, users are unlikely to change the notification permission dynamically in earlier Firefox releases. Why? Because there was no notification permission icon in the address bar.

Our studies show that users are more likely to engage with prompts that they’ve interacted with explicitly. We’ve seen that through pre-prompting in the user interface, websites can inform the user of the choice they are making before presenting a prompt. Otherwise, unsolicited prompts are denied in over 99% of cases.

We hope these changes will lead to a better user experience for all and better and healthier engagement with notifications.

About Anne van Kesteren

Standards person with an interest in privacy & security boundaries, as well as web platform architecture · he/him

More articles by Anne van Kesteren…

About Johann Hofmann

Firefox Security & Privacy Engineer

More articles by Johann Hofmann…


  1. Trevor

    Will this change impact other permission prompts? I’m thinking specifically about granting permission for camera and microphone. The browser prompt currently has a check box. If a user grants permission, but does not check the box they will be prompted every time navigator.mediaDevices.getUserMedia() is called. There are some scenarios where this causes a frustrating experience for the user.

    November 13th, 2019 at 07:45

    1. Anne van Kesteren

      This change only affects the notification permission. If you could file a bug at https://bugzilla.mozilla.org/ describing the particular frustrating scenarios that would be quite helpful. Feel free to cc me or mention it here in a follow-up comment.

      November 14th, 2019 at 00:02

      1. Trevor


        November 15th, 2019 at 15:02

  2. Martin B

    Good work! Is there any chance of a global setting? I would like to never be asked about site notifications for any site. I don’t want to get my notifications via the web

    November 13th, 2019 at 08:28

    1. Anne van Kesteren

      Better than a chance, it exists:

      Navigate to about:preferences.
      Search for “notifications”.
      Click its adjacent “Settings…” button.
      Check the “Block new requests asking to allow notifications” checkbox.
      Click “Save Changes”.

      November 14th, 2019 at 00:06

  3. jr conlin

    After a bit of poking around in my code, the following* appears to work. Am I correct in noting that Notification.requestPermission() must be in the first enclosure for the handler of the subscription request button? (FWIW, my old code had it further up the chain, so the page wouldn’t even install a service worker without permission, but that doesn’t seem to be sufficient.)

    navigator.serviceWorker.getRegistration().then( (registration) => { document.getElementById("request_subscription_button").addEventListener("click", () => { Notification.requestPermission().then( () => { registration.pushManager.subscribe().then( (subscription_info) => { // send the subscription info to the server }); }); }); });

    * please forgive any syntax errors, I’m entering that by hand and extrapolating from my page’s code.

    November 13th, 2019 at 16:28

    1. Anne van Kesteren

      I’m pretty sure that invoking either requestPermission() or subscribe() ought to work. You might also want to more eagerly register the event listener, though usually the registration should be there pretty quickly I suppose.

      November 14th, 2019 at 00:17

  4. James Browning

    I wonder if for these permission things a different approach could be taken over permission prompts. Because even with interaction required a lot of sites will still prompt again when doing any arbitrary interaction which is just as annoying (e.g. clicking a link but getting a prompt instead).

    One idea I had for dealing with this is something based on https://developers.google.com/web/updates/2019/02/intersectionobserver-v2 where browsers provide a dedicated element that can be part of the page. But in order to protect it browsers would effectively use machinery similar to IntersectionObserver v2 to ensure the element hasn’t been click-jacked, moved recently, etc to ensure the request is legitimate, this would be more predictable than prompts because if the element has a consistent UI then the user won’t be surprised.

    November 13th, 2019 at 23:11

  5. Jordan

    Thank you! So many times I get the feeling a website is just waiting for me to hover over the most desired link, which they’ve moved where the accept notification button pops-up, and “BAM!” notification request right under my cursor!

    November 14th, 2019 at 05:32

Comments are closed for this article.