Bugzilla

Is the "user" in this case the content JS, or the actual Firefox user?  Neither option is great.  QuotaManager and IndexedDB have historically erred on the side of leaving user data theoretically recoverable for the rare super-expert user and leaving things broken for every other user.  If we can't automatically mitigate the problem, then our choices are really to either wipe just the database (less spec compliant, more user friendly) or the entire origin (more spec compliant, less user friendly).

The good news is that I think I have an additional heuristic to suggest beyond my Slack comments:
- Detect when an attempt is made to access a nonexistent object store name on a database.  If the database's IDB-internal schema version indicates it was created prior to the fix landing, then we assume the database was subject to the bug.

In terms of handling that, the options seem to be:
1. See if the site handles the problem itself by either deleting the database or successfully triggering an upgrade transaction.  If either of these happen, we should leave it to the site.
2. If the site doesn't seem to do anything to fix the database, then delete the database.  It seems like 2 cases are possible here:
  a. The site keeps repeatedly opening the database and doing the same things.  In this case, if the next open of the database by the page doesn't try and perform an upgrade, delete the database.
  b. The window global closes without further accessing the database.  In this case, we should delete the database so the next open of the page doesn't see the database.

Alternately, we can wipe the origin instead of just the database.

Is the "user" in this case the content JS, or the actual Firefox user?  Neither option is great.  QuotaManager and IndexedDB have historically erred on the side of leaving user data theoretically recoverable for the rare super-expert user and leaving things broken for every other user.  If we can't automatically mitigate the problem, then our choices are really to either wipe just the database (less spec compliant, more user friendly) or the entire origin (more spec compliant, less user friendly).

The good news is that I think I have an additional heuristic to suggest beyond my Slack comments:
- Detect when an attempt is made to access a nonexistent object store name on a database.  If the database's IDB-internal schema version indicates it was created prior to the fix landing, then we assume the database was subject to the bug.

In terms of handling that, the options seem to be:
1. See if the site handles the problem itself by either deleting the database or successfully triggering an upgrade transaction.  If either of these happen, we should leave it to the site.
2. If the site doesn't seem to do anything to fix the database, then delete the database.  It seems like 2 cases are possible here:
  a. The site keeps repeatedly opening the database and doing the same things.  In this case, if the next open of the database by the page doesn't try and perform an upgrade, delete the database so that the open triggers an upgrade transaction like the database had never existed.
  b. The window global closes without further accessing the database.  In this case, we should delete the database so the next open of the page doesn't see the database.

Alternately, we can wipe the origin instead of just the database.