[Bug]: storageState({ indexedDB: true }) silently empties Map and Set values

[ayaangazali]

Version

1.64.0-next, d1ead3ecc. Reproduces identically on chromium, firefox and webkit.

Steps to reproduce

Store a Map and a Set in IndexedDB, snapshot the context, restore it into a new one:

const ctx = await browser.newContext();
const page = await ctx.newPage();
await page.goto(server.EMPTY_PAGE);
await page.evaluate(async () => {
  const db = await new Promise(res => {
    const r = indexedDB.open('probe', 1);
    r.onupgradeneeded = () => r.result.createObjectStore('s');
    r.onsuccess = () => res(r.result);
  });
  const tx = db.transaction('s', 'readwrite');
  tx.objectStore('s').put(new Map([['mk', 'mv']]), 'map');
  tx.objectStore('s').put(new Set([1, 2]), 'set');
});

const state = await ctx.storageState({ indexedDB: true });
const ctx2 = await browser.newContext({ storageState: state });
// read 'map' and 'set' back out of IndexedDB in ctx2

Expected

map comes back as a Map holding mk -> mv, set as a Set holding 1, 2. IndexedDB stores values with the structured clone algorithm, which supports both.

Actual

Both come back as empty plain objects, with no error or warning anywhere:

map -> object:{}
set -> object:{}

The loss is already visible in the snapshot itself, where both are encoded as an object with no properties:

{"key":"map","valueEncoded":{"o":[],"id":1}}
{"key":"set","valueEncoded":{"o":[],"id":1}}

Everything else I tried survives the round trip exactly, which is what made this look like an oversight rather than a deliberate subset:

num    -> number:42
str    -> string:"hello"
date   -> Date:2020-01-02T03:04:05.678Z
bytes  -> U8:1,2,250
nested -> object:{"a":[1,{"b":"c"}],"d":null}
bigint -> BigInt:9007199254740993
undef  -> undefined
map    -> object:{}      <-- was Map([['mk','mv']])
set    -> object:{}      <-- was Set([1,2])

Cause

storageScript.ts encodes records with the shared serializer in packages/isomorphic/utilityScriptSerializers.ts, and that file has explicit cases for RegExp, Date, URL, Error, ArrayBuffer, TypedArray and BigInt but none for Map or Set. With no case to match, both fall through to the generic object branch, which walks own enumerable properties. A Map has none of its contents there, so it encodes as { o: [], id: N } and parses back as {}.

Notably the types it does handle are structured clone types, so the intent looks like covering what IndexedDB can actually hold. Map and Set are structured clone types too and are just missing from the list.

Scope

I am only reporting the IndexedDB snapshot path. page.evaluate(() => new Map(...)) also yields {}, but that is the documented Serializable boundary on the evaluate return value and I assume it is intentional, so I left it out. The difference here is that storageState is a persistence feature over a store that natively holds these types, the option is pitched for real app state like Firebase auth, and nothing tells the user their data was dropped.

I am a freshman in college doing my best to be useful on real projects, so if IndexedDB snapshots are only ever meant to cover a JSON-ish subset, that would be worth a line in the option docs, and I am happy to be corrected.

[tahakotil]

I'd like to work on this one.

I traced the storage-state path first: IndexedDB records are transported as { key, keyEncoded, value, valueEncoded } (packages/protocol/src/validator.ts), so non-plain structured-clone values are meant to round-trip through the *Encoded fields. The repro in the report points at the restore side falling back to the plain value for Map/Set, which is why they come back empty in the new context.

What I would do if you are happy to take the fix from the community:

• add a regression test next to the existing IndexedDB coverage in tests/library/browsercontext-storage-state.spec.ts that stores a Map and a Set, then asserts them after storageState({ indexedDB: true }) -> new context;
• fix the snapshot/restore conversion so the encoded value is applied instead of the lossy plain value;
• run the relevant browser tests on chromium, firefox and webkit.

I can reproduce the failure from the snippet in the report. Per the contribution guide I am not opening a pull request until the issue is assigned - could you assign it to me if you want this handled by a community contributor?

I am also fine with splitting the encoded-value fix into its own change if that suits your triage better.

[ayaangazali]

Not mine to assign, that is a maintainer call. But I think the trace is off by one step, and it matters for where you would put the fix, so here is what I measured.

The values are already gone in the snapshot, before restore is involved. Straight out of storageState({ indexedDB: true }), valueEncoded is present and it is itself empty:

{"key":"map","valueEncoded":{"o":[],"id":1}}
{"key":"set","valueEncoded":{"o":[],"id":1}}

{o: [], id: N} is the encoding for a plain object with no properties. So restore is faithfully reconstructing what it was handed, and applying the encoded value instead of the plain one will not recover anything, because the contents were dropped at encode time.

The reason is in packages/isomorphic/utilityScriptSerializers.ts. innerSerialize has explicit branches for RegExp, Date, URL, Error, ArrayBuffer, TypedArray and BigInt, and then a final typeof value === 'object' branch that walks Object.keys(value). A Map has none of its entries there, so it takes that branch and comes out empty. parseEvaluationResultValue has the mirror-image gap, with cases for v, d, u, bi, ta, a, o and nothing for Map or Set. So both directions need the new case, not just restore.

Two things worth settling with a maintainer before you write it:

SerializedValue is a wire type, defined in packages/protocol/spec/serialized.yml. Adding a variant there regenerates channels.d.ts and validator.ts and is visible to the other language bindings, so this is a protocol change rather than a local fix.

And that serializer is shared with evaluate(). Today page.evaluate(() => new Map([['a',1]])) returns {}, which I left out of the report because it looks like the intended Serializable boundary. Teaching the serializer about Map and Set changes that return value too, in a very widely used API. That might be exactly what they want, or they might prefer the IndexedDB path to diverge. Worth asking, because it decides whether your regression test belongs only in browsercontext-storage-state.spec.ts or also next to the evaluate tests.

Happy to re-run my probe against whatever you end up with, I have all three browsers set up here.