Hacker News Reader

Comment by AshleysBrain | Hacker News Reader

Ideally these libraries will fall back to in-memory storage, which is lost when you navigate away, but keeps pages working when they expect to be able to write then read back a value in the same page.

Some browsers like Firefox throw exceptions when you try to touch storage in private browsing mode. This can be super annoying since it tends to break pages that use storage and haven't been specially tested in that mode in that browser. A library-based memory fallback helps avoid that. AFAIK it's what Chrome does with storage in incognito mode: just save calls in RAM, return them if asked for, then throw it away when navigating.

There's a PR to add this for localforage but it's been stuck in purgatory for a while and seems to have some resistance despite the utility: https://github.com/localForage/localForage/pull/555

View on HN

Clarification for those who parsed this (incorrectly) like I did: localStorage does work in Firefox in Private Browsing Mode[1], it's IndexedDB and the DOM Cache API that throw. (Although Firefox has private browsing support for IndexedDB in the works. That effort is tracked on https://bugzilla.mozilla.org/show_bug.cgi?id=781982.)

1: But it's exclusively memory-backed and will be forgotten somewhere between 0 and 20 seconds after the last active page for the origin is gone. It is not persistent for the lifetime of the private browsing session. However, because Firefox has a back-forward cache ("bfcache") that keeps pages around (frozen) for a while after you navigate the window to another location, the storage may be kept alive for some time even with no active windows.

I think the reasons stated for not including this PR are pretty well thought out, and while your arguments on utility seem consistent and definitely make logical sense, they don't really reflect my own development experience.

This could be just personal preference, but it seems far more likely to me that my expectation when storing values in localStorage would not match Chrome's apparent silent fallback of not storing that value. I'd much prefer to handle the error case.

localStorage can be cleared at any time anyway. This simply makes it happen on each page navigation.

IDK what you'd rather do in Chrome Incognito, Safari Private, Edge InPrivate, etc.

---

PS. If the OS registry entry for localStorage location is invalid or missing, IE will also throw an error.

What I would do in Incognito, etc. would depend on the website/app and use-case. The point was that handling that on a case by case basis makes more sense than the suggested silent (and I would say unexpected) behavioural change.

I'd say that if the user is using a private browsing mode, they are explicitly indicating to the browser not to store anything, and they will know that will happen. It's the whole purpose of the feature, so I don't think it counts as "silently" doing anything. I don't think there's any reason to then potentially break web pages that (quite reasonably) expect storage APIs to work.

Right. It's like "silently" removing session and non-session cookies when the windows closes. That's the whole point.

Reply on news.ycombinator.com