1544529 - LocalStorage should flush dirty top-level window origins to disk on window closure

Status: NEW

(Core :: Storage: localStorage & sessionStorage, defect, P3)

Description

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

Bug 1536797 covers a GeckoView scenario where LocalStorage changes never make it to disk because Gecko is terminated before flushing the storage to disk.

Right now, we flush at the earlier of the following:

• The Datastore closes because: (!mPrepareDatastoreOps.Count() && !mPreparedDatastores.Count() && !mDatabases.Count())
• The kFlushTimeoutMs = 5000 timer elapses from the first write.

I do some analysis in https://bugzilla.mozilla.org/show_bug.cgi?id=1536797#c12 that covers high level issues, but I suspect what's happening that we can improve upon is that the window gets closed and we'd expect Datastore::Close() to handle this, except there's still a prepared datastore hanging around for 20 seconds, so we end up waiting for 5 seconds, but Gecko is already terminated by the time the timer would happen.

I say top-level origins because I think it's quite possible that iframes could churn at a high rate and because only top-level windows/tabs correlate with user intent. (It's possible for an iframe to do window.open() to get a top-level window of its own, of course, but that is gated on user interaction at least.)

Comment 1

[BugBot [:suhaib / :marco/ :calixte]]

The priority flag is not set for this bug.
:overholt, could you have a look please?

For more information, please visit auto_nag documentation.

Comment 2

[Jens Stutte [:jstutte]]

I assume this is still a problem?

Comment 3

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

All the code seems to still be the same in LS(NG), yes.

Comment 4

[Pierre Bayerl]

Are there some actions planned regarding this scope. I have a PWA running into this problem, making the app quite useless/unreliable with Firefox. Is there a workaround (trigger flush from js)?