Bugzilla

Thank you!  So you were definitely at/near the LocalStorage limit (as opposed to this being highly impacted by multi-process snapshot quota pre-allocations which is something being fixed actively in another bug).

This[1] seems like a general indication that probably need to think about mitigations for LocalStorage breakage like we've done for ServiceWorkers (as motivated by slack breakage).  That is, if we throw a LocalStorage quota limit exception and it ends up propagating without being caught and we run a heuristic check that suggests the page might be broken and/or there's no indication that the site is otherwise thinking about quota concerns, we should think about expiring some or all of LocalStorage.  We did add a [last_access_time column](https://searchfox.org/mozilla-central/rev/679ebe4ffdc7312e42d55badb02ef89336af8223/dom/localstorage/ActorsParent.cpp#366) in our schema, but we haven't hooked it up to anything yet.

By spec, the granularity would be "clear the whole origin", but in practice an intervention that clears old data that has not been read or written in a long time seems reasonable.  And it would be reasonable to treat running code like I provided in comment 1 as the site seeming to take responsibility for clearing its data.  The one thing would be to make sure devtools doesn't accidentally impact this data.  Presumably we can check the principal performing access and if it's an expanded principal (for web extensions) or a system principal (for devtools), we can disable the checks having an impact.

1: Breakage of a significant site that primarily uses a single origin and that has a lot of engineering behind it.

Thank you!  So you were definitely at/near the LocalStorage limit (as opposed to this being highly impacted by multi-process snapshot quota pre-allocations which is something being fixed actively in another bug).

This[1] seems like a general indication that probably need to think about mitigations for LocalStorage breakage like we've done for ServiceWorkers (as motivated by slack breakage).  That is, if we throw a LocalStorage quota limit exception and it ends up propagating without being caught and we run a heuristic check that suggests the page might be broken and/or there's no indication that the site is otherwise thinking about quota concerns, we should think about expiring some or all of LocalStorage.  We did add a [last_access_time column](https://searchfox.org/mozilla-central/rev/679ebe4ffdc7312e42d55badb02ef89336af8223/dom/localstorage/ActorsParent.cpp#366)[2] in our schema, but we haven't hooked it up to anything yet.

By spec, the granularity would be "clear the whole origin", but in practice an intervention that clears old data that has not been read or written in a long time seems reasonable.  And it would be reasonable to treat running code like I provided in comment 1 as the site seeming to take responsibility for clearing its data.  The one thing would be to make sure devtools doesn't accidentally impact this data.  Presumably we can check the principal performing access and if it's an expanded principal (for web extensions) or a system principal (for devtools), we can disable the checks having an impact.

1: Breakage of a significant site that primarily uses a single origin and that has a lot of engineering behind it.

2: Note that `last_access_time` was introduced for determining whether we can be more clever about our initial reads of the LocalStorage database and/or what we pre-emptively send down to the content processes in a snapshot.  If we can just read 64K from disk in a first pass instead of 5M in order to reduce the initial blocking phase, that lets us help reduce the amount of time the content process has to block.  That such a field could be used for partial data-clearing was something we were aware of, but it's definitely not clear that clearing at a granularity less than the origin is appropriate.