Enhance browser.storage.local to allow storing binary data directly

[scripthunter7]

I am reaching out to propose an enhancement to the browser.storage.local functionality. As it stands, this storage currently only supports values that are serializable to JSON.

However, in some scenarios, the ability to store binary data directly can greatly enhance efficiency and performance.

To address this, I recommend integrating support for binary data formats such as Uint8Array, ArrayBuffer, or Blob without the need for JSON serialization. Certainly, maintaining backward compatibility is crucial, since a lot of existing code relies on the current storage.local API.

[gorhill]

Another approach to solve this would be to keep browser.storage.local as is while making one or both of the following APIs work reliably in incognito/private mode (related issue #534).

• CacheStorage
• IndexedDB

Extensions can already save data while in incognito/private mode through browser.local.storage so I don't see how it helps to prevent them to do so reliably through the above API.

Personally just being able to reliably use the CacheStorage API regardless of incognito/private mode would be welcome.

[oliverdunk]

We discussed this during our in-person meeting at TPAC.

In Chrome, the behavior described matches our currently intended behavior for the local and sync storage areas. I believe some (maybe all) of the data types mentioned would work in the storage.session area in Chrome since we use a different implementation. We are neutral on this issue - we don't have any specific objections but are unlikely to prioritize it in the short term since (a) it may require a non-trivial amount of work and (b) we would prefer the usage of web APIs which are more performance optimized.

Safari representatives mentioned that they are keen for developers to use extension storage APIs, and would be interested in this capability as a result.

[tophf]

Firefox switched to the IndexedDB backend for browser.storage, so it became super fast and capable of storing structured-cloneable data. Can't Chromium use the IndexedDB backend as well?

[oliverdunk]

Can't Chromium use the IndexedDB backend as well?

It's a reasonable question! I'm not aware of any work being done to investigate the feasibility of that. It sounds like something that should be possible, but is still likely a non-trivial amount of work.

[tophf]

It should be rather simple to implement in the internal JavaScript shim, i.e. the bindings wouldn't be native, but that shouldn't matter as the performance benefit would be bigger anyway. There might be some caveats like enforcing the 10MB storage quota without unlimitedStorage permission.

[tophf]

Such implementation (assuming it uses a hardcoded db name like chrome.storage.local, optionally customizable via API and/or manifest.json) would also make the database inspectable in devtools and we could even use the whole IndexedDB API directly if we need to use IDBCursor and other advanced stuff for improved performance.