inspector: getDOMStorageItems reports unavailable storage as empty

[TrevorBurnham]

Version

v27.0.0-pre (9f7ae86d8b5)

Platform

Darwin 25.6.0 arm64

Subsystem

inspector

What steps will reproduce the bug?

DOMStorageAgent::getDOMStorageItems() falls back to reading the live Storage object when its cached map is empty (src/inspector/dom_storage_agent.cc:102). If getWebStorage() can't produce that object it returns std::nullopt, and the agent simply skips the fallback and returns success with an empty entries array. A frontend cannot tell "this store is empty" from "there is no store to read".

getWebStorage() returns nothing whenever reading globalThis.localStorage throws, which its internal TryCatch swallows, or when the value is not an object. The simplest way to reach it is to enable storage inspection without configuring a backing file, so that localStorage is undefined:

// insp.mjs
import { Session } from 'node:inspector/promises';
const session = new Session();
await session.connect();
await session.post('DOMStorage.enable');
const r = await session.post('DOMStorage.getDOMStorageItems', {
  storageId: { isLocalStorage: true, securityOrigin: '', storageKey: '' },
});
console.log('entries =', JSON.stringify(r.entries));
session.disconnect();

$ node --experimental-storage-inspection insp.mjs
entries = []

How often does it reproduce? Is there a required condition?

It occurs whenever globalThis.localStorage is absent or not an object, which happens when --localstorage-file isn't given.

What is the expected behavior? Why is that the expected behavior?

A protocol error, like the neighbouring failure paths in the same function already produce: "DOMStorage domain is not enabled" when the domain is off, and "Could not read DOM storage items" when the store cannot be read.

What do you see instead?

DispatchResponse::Success() with entries: [].

Additional information

Fixing this would change what a DevTools frontend sees for a process with no --localstorage-file, which is the common case.