fix(storageState): close IndexedDB connections opened by collect and restore

[Pavel Feldman (pavelfeldman)]

Summary

• storageState({ indexedDB: true }) left the IndexedDB connections it opened in the inspected page, blocking any later deleteDatabase on that origin and making setStorageState() hang forever while a page was open there.
• Close the connections in _collectDB and _restoreDB once done.

Fixes#42258

[Pavel Feldman (pavelfeldman)]

it is just try/catch.

[github-actions]

Test results for "MCP"

1 failed
❌ [chrome] › mcp/cli-parsing.spec.ts:67 › wrong argument type @mcp-macos-latest-chrome

8100 passed, 1311 skipped

---

Merge workflow run.

[github-actions]

Test results for "tests 1"

20 flaky

⚠️ [chromium-library] › library/global-fetch.spec.ts:293 › should return security details from response `@frozen-time-library-chromium-linux`
⚠️ [chromium-library] › library/har.spec.ts:639 › should have security details `@frozen-time-library-chromium-linux`
⚠️ [chromium-library] › library/video.spec.ts:736 › screencast › should work with video+trace `@frozen-time-library-chromium-linux`
⚠️ [chromium-library] › library/global-fetch.spec.ts:293 › should return security details from response `@chromium-ubuntu-22.04-arm-node20`
⚠️ [chromium-library] › library/har.spec.ts:639 › should have security details `@chromium-ubuntu-22.04-arm-node20`
⚠️ [chromium-library] › library/global-fetch.spec.ts:293 › should return security details from response `@realtime-time-library-chromium-linux`
⚠️ [chromium-library] › library/har.spec.ts:639 › should have security details `@realtime-time-library-chromium-linux`
⚠️ [chromium-library] › library/video.spec.ts:495 › screencast › should capture static page in persistent context Radoslav Kirilov (@smoke) `@realtime-time-library-chromium-linux`
⚠️ [chromium-library] › library/global-fetch.spec.ts:293 › should return security details from response `@chromium-ubuntu-22.04-node24`
⚠️ [chromium-library] › library/har.spec.ts:639 › should have security details `@chromium-ubuntu-22.04-node24`
⚠️ [chromium-library] › library/global-fetch.spec.ts:293 › should return security details from response `@chromium-ubuntu-22.04-node20`
⚠️ [chromium-library] › library/har.spec.ts:639 › should have security details `@chromium-ubuntu-22.04-node20`
⚠️ [chromium-library] › library/global-fetch.spec.ts:293 › should return security details from response `@chromium-ubuntu-22.04-node22`
⚠️ [chromium-library] › library/har.spec.ts:639 › should have security details `@chromium-ubuntu-22.04-node22`
⚠️ [firefox-library] › library/global-fetch.spec.ts:293 › should return security details from response `@firefox-ubuntu-22.04-node20`
⚠️ [firefox-library] › library/har.spec.ts:639 › should have security details `@firefox-ubuntu-22.04-node20`
⚠️ [firefox-library] › library/heap.spec.ts:223 › should not leak workers `@firefox-ubuntu-22.04-node20`
⚠️ [webkit-library] › library/global-fetch.spec.ts:293 › should return security details from response `@webkit-ubuntu-22.04-node20`
⚠️ [webkit-library] › library/har.spec.ts:639 › should have security details `@webkit-ubuntu-22.04-node20`
⚠️ [playwright-test] › ui-mode-trace.spec.ts:715 › should indicate current test status `@windows-latest-node22`

51117 passed, 1220 skipped

---

Merge workflow run.

[github-actions]

Hi, I'm the Playwright bot and I took a first look at the CI failures.

🟢 The one failure looks like infra noise, not this PR

[chrome] › mcp/cli-parsing.spec.ts:67 › wrong argument type timed out on mcp-macos-latest-chrome, but it's an MCP CLI argument-parsing test with no connection to the IndexedDB storage change here. Reads as an isolated macOS runner stall.

Details

This PR only touches packages/injected/src/storageScript.ts (closing the IndexedDB connections opened by _collectDB/_restoreDB) and adds one browsercontext-storage-state.spec.ts test. Nothing in it reaches the MCP CLI parser.

Pre-existing flake / infra

• [chrome] › mcp/cli-parsing.spec.ts:67 › wrong argument type — infra timeout, not caused by this PR. The failure is a hard Test timeout of 30000ms exceeded (30073ms), whereas this test normally finishes in ~800ms. In the test-results DB it has a spotless record — 0 failures across ~3,500 runs (735/735 chrome, plus chromium/firefox/webkit/msedge all green), so a lone 30s stall on macos-latest points at the runner, not the test or this diff. It doesn't exercise storageState/IndexedDB in any way.

Honest caveat: with a perfect history I can't point to the same test failing elsewhere to call it a textbook flake — but the 30s-vs-800ms timeout signature plus zero diff reachability make an infra hiccup by far the most likely explanation. A rerun should come back green.

_{Triaged by the Playwright bot - agent run}