1759711 - Automatically clear origin/bucket when IDB database corruption is encountered (or just the database for the system principal), accounting for any APIs that allow for explicit handling of corruption

Status: NEW

(Core :: Storage: IndexedDB, enhancement)

Description

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

Currently we throw UnknownErr when corruption is encountered in an IndexedDB database but we should be clearing the storage bucket that contains it. Currently, there's only one bucket per origin, so this would be the entirety of the origin's storage, although practically speaking it probably makes sense to leave cookies intact and potentially even LocalStorage (although this diverges from the spec and so it's likely appropriate to discuss revising the spec, otherwise this would be categorized as an intervention). In the case of corruption for IDB databases stored against the system principal (ex: remote settings in bug 1759247), just the individual database should be cleared.

The only time we wouldn't clear the entirety of the origin would be if something like https://github.com/wanderview/storage-corruption-reporting/blob/master/explainer.md becomes standardized, in which case we'd allow content a chance to handle things.

Comment 3

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

I did some brief investigation in https://bugzilla.mozilla.org/show_bug.cgi?id=1258596#c3 and it's worth summarizing that:

• Currently we will automatically delete databases that are corrupt as determined at open time via mozilla::dom::quota::IsDatabaseCorruptionError and this will lead to us opening the database anew.
• We don't currently do anything with the bucket.
• There is still no handling for dynamically detected corruption (which we expect to be most detected corruption).
• This does not handle the case that the schema is from the future! Although this should never happen anymore, it would probably be nice to address that concern of bug 1258596 and have us deal with schema-from-the-future by treating the database like it is corrupt. In particular, since it's so hard to create that situation now, it's probably more likely to just be a different form of corruption. Of course, if we change to using AEAD on all IDB databases (not just PBM ones) or otherwise are confident any corruption in the DB header will be detected, that potentially does change things.