# How to test the notification permission prompt again > Chrome asks a site once and keeps the answer, so the tester sees nothing next time. Reset the site's permission, or open a profile that has never visited. Source: https://mosaicbrowser.com/blog/notification-prompt-again ## Seeing the notification prompt again, as a new visitor would Chrome asks a site once and keeps the answer, so the tester sees nothing next time. Reset the site's permission, or open a profile that has never visited. ![Every fresh profile is a first visit, beside a screenshot: creating a profile in Mosaic: a checked proxy, and the hardware and locale drawn to match its exit](https://mosaicbrowser.com/covers/notification-prompt-again.webp) To test a notification permission prompt again, you have to give the browser back its first-visit state, because Chrome asks each site once and remembers the answer. Reset the permission in the site's settings, or open the page in a browser profile that has never been there. On a first visit `Notification.permission` reads `default`, and only then can `Notification.requestPermission()` show the prompt. ## Why the prompt stops appearing The permission has three states. `default` means nobody has decided. `granted` and `denied` mean somebody has, and from then on a call to `requestPermission()` resolves with the stored answer and draws nothing. So the most common bug report for a push opt-in flow, "the prompt does not show any more", usually means the tester's browser already said yes or no on an earlier run. There is a quieter version of the same thing. If you close the prompt with its x several times instead of choosing, Chrome can start holding requests back for that site for a while, and the console says the permission was blocked because the prompt was dismissed several times. During that pause the page can read `denied` although nobody ever pressed Block, so a tester who checks only that value will go looking for a click that never happened. Chrome can also swap the full prompt for a quieter one, a small crossed-out bell in the address bar, which is easy to miss in a test and looks like nothing appeared. Mosaic is a desktop app Email yourself the link and open it on your computer. [How it works: Machines that exist](https://mosaicbrowser.com/features/real-fingerprints) ## Three ways to get a first visit back 1. **Reset the site's permission.** Click the icon to the left of the address, open the site settings and reset notifications to Ask. `chrome://settings/content/notifications` lists every site that has an answer. Reload the page afterwards. 2. **Clear more than the permission.** A push flow also leaves a service worker and a subscription behind. Unregister the worker in DevTools under Application, or clear the site's data, or your next test starts half-subscribed. 3. **Use a browser profile that has never seen the site.** This is the only one that is a first visit by construction, because nothing has to be undone. It is also the one that scales past a single tester ([a fresh profile per test run](https://mosaicbrowser.com/blog/fresh-profile-per-test-run) covers why leftover state makes tests flaky). Incognito looks like the shortcut and is not. Chrome handles notification requests differently there, so the prompt you test in Incognito is not the one your visitors get. ## The value a new visitor has, and how we got it wrong Testing as a new visitor assumes your test browser starts where a real one does. Ours did not, for a while, and the way it failed is worth knowing if you build test setups yourself. Mosaic launched every profile with the notifications content setting forced to block. The reason was real when we wrote it: each profile had its own macOS app identity, and macOS greets every new identity with a notifications banner, so a test run that made forty profiles made forty banners. When we moved app identities to one per window slot, the banner stopped being a problem, but the forced setting stayed. Every profile on our machine, 344 of them, answered `denied` where an unconfigured Chrome answers `default` ([the whole story](https://mosaicbrowser.com/blog/notification-permission-denied), with the check that excused it). For a QA team that was two faults in one. A site could read the same unusual value on every profile, and nobody testing an opt-in flow in those profiles could ever see the prompt, because the browser had refused before the page asked. We made blocking a per-profile switch, "Block web notifications" in the profile editor, off by default. Measured afterwards through the app: `Notification.permission` read `"default"` and `navigator.permissions.query({name: 'notifications'})` read `"prompt"`. ## Ask twice The question that finds this kind of fault is not "does it work" but "does it work twice". Every manual test is a first call, which is how [geolocation that answered only the first call](https://mosaicbrowser.com/blog/geolocation-answered-once) got past us. For notifications the checks are short: - a new profile reads `default` before the page asks - the prompt appears on a click - after Allow or Block, the same profile reads `granted` or `denied` and the next call shows nothing - a second new profile reads `default` again In Mosaic, each profile is its own browser with its own permissions, cookies and service workers, so a new one is a new visitor and an old one remembers exactly what its tester clicked. Name them by what they are testing ([keeping QA test accounts straight](https://mosaicbrowser.com/blog/qa-test-accounts-naming) has a way to label them), and keep the one that said yes apart from the one that said no. ## Questions ### How do I get Chrome to show the notification prompt again? Click the site icon left of the address, open the site settings and reset the notifications permission, or find the site in chrome://settings/content/notifications. Reload, and the next requestPermission() call can prompt again. ### Why does requestPermission() return denied without showing anything? Because that browser already answered for that site. A Block is remembered, and after a prompt is closed several times in a row Chrome can hold requests back for a while. Either way the call resolves with denied and no window appears. ### Can I test the prompt in an Incognito window? Not reliably. Chrome treats notification requests in Incognito differently from a normal window, so what you see there is not what a new visitor sees. ### What should Notification.permission say on a first visit? default. It changes to granted or denied only after somebody answers. The Permissions API reports the same state as prompt. ## Related [344 profiles said "denied": one value, everywhere](https://mosaicbrowser.com/blog/notification-permission-denied): Notification permission became a fingerprint: Notification.permission read denied on all 344 of our profiles, where an unconfigured Chrome says default. [A fresh browser for every test run, and why it should be cheap](https://mosaicbrowser.com/blog/fresh-profile-per-test-run): Leftover cookies and storage are where flaky browser tests come from. A one-time profile gives each run a clean jar and trashes itself when its browser closes. [A spoof that answers once: the geolocation bug we shipped](https://mosaicbrowser.com/blog/geolocation-answered-once): A geolocation spoofing timeout we shipped: the first getCurrentPosition got the exit's coordinates, every later call failed with code 3. One latch was to blame. [Keeping twenty QA test accounts straight](https://mosaicbrowser.com/blog/qa-test-accounts-naming): Managing test accounts for QA goes wrong when the state lives in people's heads. Give each persona a profile with its login, role and state beside it. [Machines that exist: fingerprints drawn from real hardware](https://mosaicbrowser.com/features/real-fingerprints): Mosaic draws each profile's GPU, screen, CPU, memory and fonts from one real device, so the parts of a fingerprint agree with each other and with the host. [Testing date and deadline features in another timezone](https://mosaicbrowser.com/blog/testing-in-another-timezone): Midnight cut-offs and "ends today" banners break in zones you don't live in. Test a website in a different timezone without touching your computer's clock. [49 browser fingerprint detectors, and how we read them](https://mosaicbrowser.com/blog/forty-nine-detectors): Our browser fingerprint detectors list: 49 public test pages in five groups, 40 read by a script and 9 kept as reference because they print no verdict. [Seeing both sides of your own A/B test](https://mosaicbrowser.com/blog/seeing-both-ab-variants): Testing tools put each visitor in one variant by a cookie or id and keep them there. To see every variant, keep one browser profile per variant for the test. ## Mosaic, on your own computer The browser this blog is about: its own Chromium, fingerprints from real machines and a proxy exit per profile. Free holds 3 profiles. Pro is $49 a month for any number. Mosaic is a desktop app Email yourself the link and open it on your computer.