Open Bug 1703317 Opened 3 years ago Updated 2 years ago

Have LSNG fall back to using non-disk-backed in-memory storage in the event of breakage

Categories

(Core :: Storage: localStorage & sessionStorage, enhancement, P2)

enhancement

Tracking

()

People

(Reporter: asuth, Unassigned)

Details

The largest problem we experienced during the initial attempt at enabling LSNG on release was that LocalStorage would synchronously throw in failure cases, which frequently broke sites that were not expecting this. From a spec perspective, the synchronous throwing made sense, but the reality is that no one is prepared for that (and arguably no one should have to be prepared for that).

As a mitigation, we should ensure that, in the event of QuotaManager / LSNG problems, our failure mode is one of the following:

  1. Durable-in-memory: We act like private browsing mode where storage is retained in-memory for the lifetime of the browser. LocalStorage access does not throw except when quota limits are reached. LocalStorage for an origin will persist even if all pages for an origin are closed for many minutes, and then a page for the origin is opened.
  2. Durable-while-in-use or durable-while-recently-in-use: LocalStorage for an origin persists while in use, but if a user closes all pages for an origin for many minutes, the storage will be gone when they go back.

The general rationale for either choice is:

  • This is an attempt to minimize the impact of the serious failure mode of QuotaManager being broken (something we've been improving significantly over time and now have extensive telemetry to support our continued improvements of the long part of the long tail).
  • This is not an attempt to create a newly supported mode.
  • The most important thing here is to ensure that LocalStorage APIs don't throw. The durability/lifetime of the data is significantly less of a concern that not breaking JS in web pages. We understand that there may be support requests in this mode, and that's good because unfortunately "Refresh Firefox" is unfortunately required in this cases until such time as QuotaManager's self-healing machinery is able to correct things.
You need to log in before you can comment on or make changes to this bug.