1405318 - Prototype Firefox 57 downgrade backport for DOM Cache API v26 and Quota Manager v3 schemas.

Status: RESOLVED DUPLICATE of bug 1404344

(Core :: Storage: Quota Manager, enhancement, P1)

Comment 1

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

Attachment: Part 1: QuotaManager changes

Comment 2

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

Attachment: Part 2: DOM Cache API changes

Comment 3

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

Attachment: Part 3: Rename QuotaManager tests from 3_0 to 2_1

Comment 4

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

With these changes, I was able to do:
- Create fresh profile in 56, visit pokedex.org, things work.
- Run under current 57 beta, visit pokedex.org, things work.
- Run under 56 again, visit pokedex.org, IndexedDB errors everywhere.
- Run under modified trunk build with these changes (which should also work on 57, I'll graft now), visit pokedex.org, things work (as is expected.)
- Verify schema downgrades took in the profile schema version.
- Run under 56 again, visit pokedex.org, things work.

The bad news is that this doesn't fix things for Firefox 56 debug builds for the DOM Cache API.  The DOM Cache API is very thorough about validating the schema, and it will notice that the column 57 added is there and it will fail to open.  It will not delete data.

But since we don't expect downgrading end-users to use debug builds, maybe this is okay?

How horrible is this?

Comment 5

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

Oh, and I also verified via gdb that GetEffectiveSchemaVersion from part 2 correctly returns 27 under the modified build after returning from using the profile under 56, etc.

Comment 6

[Andrew Overholt [:overholt]]

(In reply to Andrew Sutherland [:asuth] from comment #4)
> But since we don't expect downgrading end-users to use debug builds, maybe this is okay?

I think we could probably live with this. Romain?

Comment 7

[Jan Varga [:janv]]

(In reply to Andrew Sutherland [:asuth] from comment #4)
> How horrible is this?

As I said, if we fail with all other options, we can take this.

Comment 8

[Ben Kelly [:bkelly, not reviewing]]

I think this is a bad idea, but ok.  We should be clear we're not doing this again for future releases.  Product/UX need to come up with a long term solution.

Comment 9

[Romain Testard [:RT]]

(In reply to Andrew Overholt [:overholt] from comment #6)
> (In reply to Andrew Sutherland [:asuth] from comment #4)
> > But since we don't expect downgrading end-users to use debug builds, maybe this is okay?
> 
> I think we could probably live with this. Romain?

That sounds OK to me, can you although confirm what "fail to open" means from a user standpoint?

How could this fix be shipped to users?

Comment 10

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

(In reply to Romain Testard [:RT] from comment #9)
> How could this fix be shipped to users?

We land these patches on Firefox 57 beta.  So:
- Users who receive the Firefox 57 release (with the patch) and then downgrade are okay.
- Users who get the next non-dev-edition (which we should not be promoting) Firefox 57 beta (with the patch) who are mixing Firefox 56 and Firefox 57 can switch between them without problems.

> That sounds OK to me, can you although confirm what "fail to open" means
> from a user standpoint?

DOM Cache API will be broken, same as if we didn't land these patches at all.  Although for a slightly different reason.

The general scenario of badness for this whole family of problems is:
- Subsystem goes to open SQLite database.
- Subsystem checks the schema version we store in the user database.
- Subsystem decides the version is from the future, refuses to initialize subsystem.

In the "downgrade to Firefox 56 debug-build from any Firefox 57 w/patch" scenario here for the DOM Cache API, there's an extra step which happens:
- Subsystem checks the database schema itself, refuses to initialize subsystem.


Note that DOM Cache API only does this when a page/ServiceWorker attempts to use the DOM Cache API for a specific origin.  This differs from Quota Manager which is a global thing that initializes once.

Comment 11

[Andrew Overholt [:overholt]]

Is the work still happening here or is it in bug 1404344 instead?

Comment 12

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

Bug 1404344 for purposes of centralizing tracking flags and consolidating discussion.  Duping over.