1570234 - Accessing localStorage on about pages throws an error

Status: RESOLVED WONTFIX

(Core :: Storage: localStorage & sessionStorage, defect)

Description

[Johann Hofmann [:johannh]]

STR: Go to any about page (like about:protections) and try to access "localStorage" in the console. You'll get an NS_ERROR_NOT_AVAILABLE.

Baku mentioned that this is probably caused by https://searchfox.org/mozilla-central/rev/38c88cbf4be87dfa0636d15a5d3599a8ea0d1a72/dom/storage/StorageUtils.cpp#33 where about: pages don't have a non-empty host and as such should probably get a similar exception to file:// URIs.

Andrew, can you please take a look at this? Do you think we could solve this by simply using the origin of the page for about: pages? Is there anything else to it?

If the solution is as easy as it seems, it would be great if we could fix this quickly since it's blocking bug 1568139 which is part of Skyline work.

Thanks!

Comment 1

[Andrew Sutherland [:asuth] (he/him)]

So, yes, GenerateOriginKey has been enforcing that limitation for a while and we intentionally stuck with it in LSNG at https://searchfox.org/mozilla-central/rev/38c88cbf4be87dfa0636d15a5d3599a8ea0d1a72/dom/localstorage/LSObject.cpp#267.

localStorage has the potential to synchronously jank a whole process, has bad memory-usage characteristics, and generally we need to be dogfooding the APIs we are trying to recommend to web developers. (Both so that we have internal coverage/clients to optimize for, but also so we don't fall into a "do as I say, not as I do" situation with the recommendations we make.)

You want to be using the Cache API (https://developer.mozilla.org/en-US/docs/Web/API/Cache) if you're dealing with Request/Response data or IndexedDB otherwise. Feel free to needinfo me on any implementation bugs or schedule calendar events if you'd like to have video discussions. I'd recommend https://github.com/jakearchibald/idb if you want a slightly more ergonomic IDB interface.

Comment 2

[Johann Hofmann [:johannh]]

Huh, given the widespread usage of localStorage and the fact that it isn't exactly publicly deprecated it feels like something we should be able to dogfood and get internal coverage for, too. IndexedDB is quite complex for our use case and pulling a third party library into Firefox code just for that isn't really what we want to do either. We need a simple key-value cache but we're not dealing with HTTP requests, either.

I guess we'll have to cache in the parent process and/or add a better loading state. :(

GenerateOriginKey has been enforcing that limitation for a while

It would be nice if that function was actually enforcing this by checking and returning an explicit error code for about: principals, otherwise this is really confusing.

Comment 3

[Jan Varga [:janv]]

We went through this already, see bug 789348. Yes, localStorage is used a lot on the web, but I think that's not a reason for using it internally.
New local storage implementation only supports the best-effort storage (data can be evicted anytime), not sure if that's what you want for about pages.

Comment 4

[Andrew Sutherland [:asuth] (he/him)]

If you want something more explicitly standards track than the idb wrapper library, KVStorage is basically a simpler key/value store built on IndexedDB that will be a shipped standard:

• spec https://wicg.github.io/kv-storage/
• repo https://github.com/WICG/kv-storage

It's not fully locked down yet, though.