When WebExtensions have the "unlimitedStorage" permission we're setting an "indexedDB" permission to ALLOW for their principal. In bug 1451486 we said that it's probably fair to keep doing this until ~62 to give the few WE users a chance to migrate (since data loss is likely to be much worse for WebExtensions than for websites which always have to deal with users clearing their cookies and site data). When we're removing the indexedDB permission we should clear this part up as well: https://searchfox.org/mozilla-central/rev/f860c2bf00576959b07e2d9619c7b5088b0005be/toolkit/components/extensions/Extension.jsm#1559,1565

While migrating Brief from the "persistent" storage to the default one, I observed several bug reports where "persistent" storage works correctly while the "default" one fails with UnknownError ("The operation failed for reasons unrelated to the database itself and not covered by any other error code") when the extension tries to open the DB. Is there anything that can be done to fix this breakage, or is telling the user to create a new Firefox profile if he wants to continue using Brief the only way?

(In reply to Denis Lisov from comment #1) > While migrating Brief from the "persistent" storage to the default one, I > observed several bug reports where "persistent" storage works correctly > while the "default" one fails with UnknownError ("The operation failed for > reasons unrelated to the database itself and not covered by any other error > code") when the extension tries to open the DB. Is there anything that can > be done to fix this breakage, or is telling the user to create a new Firefox > profile if he wants to continue using Brief the only way? Sounds like you should file a bug on this, ideally with steps to reproduce (or anything else you suspect might be the cause). Thanks!

(In reply to Johann Hofmann [:johannh] from comment #2) > (In reply to Denis Lisov from comment #1) > > While migrating Brief from the "persistent" storage to the default one, I > > observed several bug reports where "persistent" storage works correctly > > while the "default" one fails with UnknownError ("The operation failed for > > reasons unrelated to the database itself and not covered by any other error > > code") when the extension tries to open the DB. Is there anything that can > > be done to fix this breakage, or is telling the user to create a new Firefox > > profile if he wants to continue using Brief the only way? > > Sounds like you should file a bug on this, ideally with steps to reproduce > (or anything else you suspect might be the cause). > > Thanks! Well, I really would if I had steps to reproduce or at least access to such a profile. Unfortunately, that's not the case. The only information I have is "something is broken in some profiles so that IndexedDB does not even create a database".

Based on the description of comment 1, it sounds like there's probably a rogue file like ".desktop" in storage/default/ or storage/temporary/ as we're tracking and proposing a fix for in bug 944918. One asymmetry in QuotaManager is that "persistent" quota does not track usage and so does not have an initialization phase that scans the file-system, whereas "default" and "temporary" do and these can freak out and break for legacy reasons that we are only now beginning to be able to address as engineers re-join the team.