[Bug]: `browserContext.setStorageState()` never settles when the state contains IndexedDB and a page of the context is open on that origin

[Snooz82]

Version

1.62.1

Steps to reproduce

browserContext.storageState({ indexedDB: true }) leaves an open IndexedDB connection in the page it reads from. That connection then blocks any later attempt to delete or recreate the database on that origin — including the one browserContext.setStorageState() performs internally. The result is a promise that never settles and never times out.

Two independent symptoms follow from the same leaked connection:

1. After storageState({ indexedDB: true }), indexedDB.deleteDatabase() in the page fires onblocked instead of onsuccess.
2. setStorageState() with a state containing IndexedDB hangs forever while a page of the context is open on that origin. It is not affected by context.setDefaultTimeout().

Reproduction (Chromium, macOS; any origin works — the snippet uses example.com):

const { chromium } = require('playwright');

const SEED = async () => {
  const req = indexedDB.open('rfdb', 1);
  req.onupgradeneeded = () => req.result.createObjectStore('kv');
  const db = await new Promise((res, rej) => {
    req.onsuccess = () => res(req.result);
    req.onerror = () => rej(req.error);
  });
  await new Promise((res, rej) => {
    const tx = db.transaction('kv', 'readwrite');
    tx.objectStore('kv').put('token-abc', 'auth');
    tx.oncomplete = () => res();
    tx.onerror = () => rej(tx.error);
  });
  db.close();
};

const DELETE = async () => {
  await new Promise((res, rej) => {
    const req = indexedDB.deleteDatabase('rfdb');
    req.onsuccess = () => res();
    req.onerror = () => rej(req.error);
    req.onblocked = () => rej(new Error('blocked'));
  });
};

(async () => {
  const browser = await chromium.launch();

  // Symptom 1: storageState({indexedDB}) leaves a connection open.
  for (const withSave of [false, true]) {
    const context = await browser.newContext();
    const page = await context.newPage();
    await page.goto('https://example.com/');
    await page.evaluate(SEED);
    if (withSave) await context.storageState({ indexedDB: true });
    let result = 'ok';
    try {
      await page.evaluate(DELETE);
    } catch {
      result = 'BLOCKED';
    }
    console.log(`storageState({indexedDB}) called first = ${withSave} -> deleteDatabase ${result}`);
    await context.close();
  }

  // Symptom 2: setStorageState() never settles, and ignores the context timeout.
  const context = await browser.newContext();
  context.setDefaultTimeout(3000);
  const page = await context.newPage();
  await page.goto('https://example.com/');
  await page.evaluate(SEED);
  const state = await context.storageState({ indexedDB: true });
  const outcome = await Promise.race([
    context.setStorageState(state).then(() => 'resolved', (e) => 'rejected: ' + e.message),
    new Promise((res) => setTimeout(() => res('still pending after 20s'), 20000)),
  ]);
  console.log(`setStorageState -> ${outcome}`);
  process.exit(0);
})();

Expected behavior

storageState({ indexedDB: true }) closes the IndexedDB connections it opens, so that the page it read from is left exactly as it was found. setStorageState() restores the state regardless of whether pages of the context are open on the affected origin, and — if it genuinely cannot proceed — rejects within the context timeout rather than hanging.

Actual behavior

storageState({indexedDB}) called first = false -> deleteDatabase ok
storageState({indexedDB}) called first = true  -> deleteDatabase BLOCKED
setStorageState -> still pending after 20s

The promise returned by setStorageState() never settles. context.setDefaultTimeout(3000) has no effect on it.

Additional context

Workarounds

Anything that drops the page's IndexedDB connections before setStorageState() makes it resolve, and the data is then restored correctly:

Between storageState() and setStorageState()	Result
nothing	hangs
page.reload()	resolves, value restored
page.goto('about:blank')	resolves, value restored
page.close()	resolves, value restored
restore into a different, freshly created context	resolves, value restored

Environment

• Playwright: 1.62.1
• Browser: Chromium (bundled)
• OS: macOS 15 (Darwin 25.5.0), arm64
• Node.js: v22.20.0

Environment

System:
    OS: macOS 26.5.1
    CPU: (12) arm64 Apple M2 Max
    Memory: 71.11 MB / 32.00 GB
  Binaries:
    Node: 22.20.0 - /Users/XXX/.nvm/versions/node/v22.20.0/bin/node
    Yarn: 1.22.22 - /Users/XXX/.nvm/versions/node/v22.20.0/bin/yarn
    npm: 11.6.2 - /Users/XXX/.nvm/versions/node/v22.20.0/bin/npm
    pnpm: 10.30.3 - /Users/XXX/.nvm/versions/node/v22.20.0/bin/pnpm
  IDEs:
    VSCode: 1.132.0 - /usr/local/bin/code
    Claude Code: 2.1.233 - /Users/XXX/.local/bin/claude
    Codex: 0.147.0 - /Users/XXX/.local/bin/codex
  Languages:
    Bash: 3.2.57 - /bin/bash
  npmPackages:
    playwright: ^1.62.1 => 1.62.1

[Snooz82]

Pavel Feldman (@pavelfeldman) Nice quick fix.

I did not try your dix yet, but the setStorageState has also issues if the actual app holds the connection.
The workarounds I listed do not survive contact with a real application.

The original report blamed the connection that storageState({ indexedDB: true }) itself leaves open. That is only one instance of the general case: setStorageState() never settles while any client on the origin holds an open IndexedDB connection — including the connection the application under test opens on its own. Playwright's restore deletes the database, and deleteDatabase() blocks on any open connection, so the restore waits forever.

This matters because a fresh context does not help. What decides the outcome is whether a page on the origin currently holds a connection, not which context it belongs to:

Situation when setStorageState() is called	Outcome
Fresh context, page on the origin, app holds an open connection	hangs
Fresh context, page on the origin, no connection open	resolves
Fresh context, page on about:blank only	resolves
Fresh context, no page at all	resolves
Same context, database exists, connection closed	resolves
Same context, database exists, connection open	hangs

So the page.reload() workaround from the original report only works for a page that opens IndexedDB briefly and closes it. Any application that keeps its connection open — which is the normal pattern for the Firebase/Firestore-style auth storage that motivates indexedDB: true in the first place — reopens the connection as soon as the reload completes, and the next setStorageState() hangs again. Closing the context and opening a new page on the same application does not help either, for the same reason.

Reproduction (Chromium; the page here stands in for an application that keeps its connection open):

const { chromium } = require('playwright');

const APP_OPENS_IDB = async () => {
  const req = indexedDB.open('appdb', 1);
  req.onupgradeneeded = () => req.result.createObjectStore('kv');
  const db = await new Promise((res, rej) => {
    req.onsuccess = () => res(req.result);
    req.onerror = () => rej(req.error);
  });
  await new Promise((res, rej) => {
    const tx = db.transaction('kv', 'readwrite');
    tx.objectStore('kv').put('token', 'auth');
    tx.oncomplete = () => res();
    tx.onerror = () => rej(tx.error);
  });
  window.__db = db; // never closed, like a real application
};

const race = (p, ms) =>
  Promise.race([p.then(() => 'resolved'), new Promise((r) => setTimeout(() => r('HANGS'), ms))]);

(async () => {
  const url = 'https://example.com/';
  const browser = await chromium.launch();

  const source = await browser.newContext();
  const sourcePage = await source.newPage();
  await sourcePage.goto(url);
  await sourcePage.evaluate(APP_OPENS_IDB);
  const state = await source.storageState({ indexedDB: true });
  await source.close();

  // Fresh context, but the page holds an open connection.
  const a = await browser.newContext();
  const pageA = await a.newPage();
  await pageA.goto(url);
  await pageA.evaluate(APP_OPENS_IDB);
  console.log('app holds an open connection ->', await race(a.setStorageState(state), 8000));

  // Same, but the page is navigated away first.
  const b = await browser.newContext();
  const pageB = await b.newPage();
  await pageB.goto(url);
  await pageB.evaluate(APP_OPENS_IDB);
  await pageB.goto('about:blank');
  console.log('navigated to about:blank first ->', await race(b.setStorageState(state), 8000));

  process.exit(0);
})();

app holds an open connection -> HANGS
navigated to about:blank first -> resolved

The only reliable workarounds I have found are to remove every page from the origin before restoring — page.goto('about:blank') or page.close(), then setStorageState(), then navigate back — or to pass the state to browser.newContext({ storageState }) instead, which applies it before any page exists. Both restore the data correctly.

Two suggestions, in order of preference:

1. Have the restore cooperate with open connections the way the platform intends: an upgrade/delete request fires versionchange on every open connection, and a well-behaved holder closes on it. Playwright could send the delete and, if it is blocked, close the affected pages' connections or surface which origin is blocking, rather than waiting indefinitely.
2. Failing that, make the call time out. It currently ignores browserContext.setDefaultTimeout() entirely — 20 s of waiting under a 3 s default timeout — so callers cannot even bound it themselves.

For what it is worth, a page can detect the condition from JavaScript, which is what we now use to turn the hang into an actionable error message. Attempting an upgrade and aborting it in upgradeneeded is non-destructive and works on Chromium, Firefox and WebKit:

const dbs = await indexedDB.databases();
const blocked = await Promise.all(dbs.map(({ name, version }) => new Promise((resolve) => {
  const req = indexedDB.open(name, (version || 1) + 1);
  let settled = false;
  const done = (v) => { if (!settled) { settled = true; resolve(v); } };
  req.onblocked = () => done(true);
  req.onupgradeneeded = () => { req.transaction.abort(); };
  req.onerror = (e) => { e.preventDefault(); done(false); };
  req.onsuccess = () => { req.result.close(); done(false); };
})));

If Playwright had the same information at the point where the restore blocks, the failure could be reported instead of hung.

Best regards from the team of
Robot Framework Browser (the playwright based keyword library)
Any many thanks again from the whole user base of Robot Framework Browser for making this awesome tool.
https://robotframework-browser.org