How to Test Web Notification Permission with Playwright: Complete 2026 Guide

1. Why Testing Notification Permissions Is Harder Than It Looks

The Notification API looks simple on the surface. Call Notification.requestPermission(), get back a string (granted, denied, or default), and branch your UI accordingly. In practice, testing this flow involves at least five structural challenges that no amount of DOM manipulation can solve directly.

First, the permission dialog is a browser-native UI element, not part of the DOM. You cannot query it with page.locator() or click its buttons with page.click(). It lives outside the web content area, managed entirely by the browser chrome. Playwright solves this through its browserContext.grantPermissions() API, but understanding when and how to use it is not obvious from the documentation alone.

Second, the permission state is tri-state, not binary. Most developers test "allow" and "deny" but forget about the "default" state, which occurs when the user dismisses the dialog without choosing. In the default state, Notification.permission remains "default", and your app can request permission again on the next interaction. Handling this correctly in your UI (showing the prompt button again, for example) requires a separate test path.

Third, permission state persists across page navigations within the same browser context. A test that grants permission in one scenario will still have that permission in the next scenario unless you explicitly create a new context. This causes hidden state leakage between tests that produces intermittent failures depending on test execution order.

Fourth, push notifications involve a service worker lifecycle that operates independently from the page. The PushManager.subscribe() call requires an active service worker registration, a valid VAPID public key, and the notification permission to already be granted. Testing this chain requires orchestrating three asynchronous operations in the correct order. Fifth, different browsers handle the permission prompt differently. Chrome shows an infobar, Firefox shows a doorhanger popup, and Safari uses its own modal sheet. While Playwright abstracts this away in Chromium, your CI pipeline may need to account for these differences if you run cross-browser tests.

2. Setting Up Your Test Environment

Before writing any notification permission test, your environment needs two things: a Playwright configuration that handles permission grants at the browser context level, and a minimal app that implements the Notification API so you have something real to test against. Unlike most web APIs, notification permissions cannot be reset through JavaScript alone. They require a fresh browser context for each permission state you want to test.

Playwright Configuration

The critical Playwright setting for notification tests is permissions on the browser context. Playwright lets you pre-grant or leave unset the "notifications" permission before any page loads. This bypasses the native dialog entirely, which is exactly what you want for most scenarios. For the denial and dismissal scenarios, you need to intercept the permission request at the JavaScript level instead.

VAPID Key Generation for Push Tests

Push notification tests require a VAPID (Voluntary Application Server Identification) key pair. Generate one using the web-pushlibrary and store the keys in your test environment. The public key goes into your service worker's subscribe call; the private key is used server-side to send push messages.

Environment Variables

3. Scenario: Granting Notification Permission

import { test, expect } from '@playwright/test';

test('grant notification permission', async ({ context, page }) => {
  await context.grantPermissions(['notifications'], {
    origin: 'http://localhost:3000',
  });
  await page.goto('/');
  await page.getByRole('button', { name: /enable notifications/i }).click();
  await expect(page.getByText(/notifications enabled/i)).toBeVisible();
  const permission = await page.evaluate(() => Notification.permission);
  expect(permission).toBe('granted');
  await expect(
    page.getByRole('button', { name: /enable notifications/i })
  ).not.toBeVisible();
});

4. Scenario: Denying Notification Permission

import { test, expect } from '@playwright/test';

test('deny notification permission', async ({ page }) => {
  await page.addInitScript(() => {
    Object.defineProperty(Notification, 'permission', {
      get: () => 'denied', configurable: true,
    });
    Notification.requestPermission = async () => {
      Object.defineProperty(Notification, 'permission', {
        get: () => 'denied', configurable: true,
      });
      return 'denied';
    };
  });
  await page.goto('/');
  await page.getByRole('button', { name: /enable notifications/i }).click();
  await expect(page.getByText(/notifications blocked/i)).toBeVisible();
  const permission = await page.evaluate(() => Notification.permission);
  expect(permission).toBe('denied');
});

5. Scenario: Dismissing the Permission Prompt

6. Scenario: Push Subscription After Permission Grant

7. Scenario: Service Worker Notification Display

import { test, expect } from '@playwright/test';

test('show notification via service worker', async ({ context, page }) => {
  await context.grantPermissions(['notifications'], {
    origin: 'http://localhost:3000',
  });
  await page.goto('/');
  await page.evaluate(async () => {
    const reg = await navigator.serviceWorker.ready;
    await reg.showNotification('New Message', {
      body: 'You have a new message from Alice',
      tag: 'message-alice-123',
      actions: [
        { action: 'reply', title: 'Reply' },
        { action: 'dismiss', title: 'Dismiss' },
      ],
    });
  });
  const notifs = await page.evaluate(async () => {
    const reg = await navigator.serviceWorker.ready;
    const n = await reg.getNotifications();
    return n.map(x => ({ title: x.title, body: x.body }));
  });
  expect(notifs).toHaveLength(1);
  expect(notifs[0].title).toBe('New Message');
});

8. Scenario: Permission State Persistence Across Navigation

9. Common Pitfalls That Break Notification Test Suites

Notification permission tests fail in CI more often than any other browser API test. The following pitfalls are sourced from real GitHub issues and Stack Overflow threads on Playwright notification testing.

Debugging Failed Notification Tests

10. Writing These Scenarios in Plain English with Assrt

The Playwright examples in this guide work, but they require understanding browser context permissions, JavaScript API overrides, service worker evaluation, and route interception. Each scenario is 20 to 50 lines of TypeScript. Assrt lets you describe the same scenarios in plain English and compiles them into the Playwright code you saw above.

Here is the complete notification permission test suite from sections 3 through 8, written as an Assrt scenario file. Each scenario block maps to one of the Playwright tests above.

Assrt compiles each scenario block into the same Playwright TypeScript you saw in the preceding sections, committed to your repo as real tests you can read, run, and modify. When the browser changes how permission dialogs work, or when the Notification API spec updates, Assrt detects the failure, analyzes the new behavior, and opens a pull request with updated test code. Your scenario files stay untouched.

Start with the permission grant happy path. Once it is green in your CI, add the denial scenario, then dismissal, then push subscription, then service worker notification display, then permission persistence. In a single afternoon you can have complete notification permission coverage that most web applications never achieve by hand.