- From: Andrew Sutherland <notifications@github.com>
- Date: Tue, 01 May 2018 13:08:57 -0700
- To: w3c/IndexedDB <IndexedDB@noreply.github.com>
- Cc: Subscribed <subscribed@noreply.github.com>
- Message-ID: <w3c/IndexedDB/issues/237/385775139@github.com>
> If the information is not conveyed then it'll require apps to perform sync logic on every page load. Even if commit failures are rare, the fact that they can happen means developers will have to account for them, and without any signals from the browser they'll have to manually check for inconsistencies. Would the background sync API be sufficient here? A page can check if there's an outstanding sync tag via the SyncManager API if it needs to, plus it can also just be event-driven on this front by just processing the "sync" event(s). As long as the IndexedDB commit's success is tied to resolving the sync event's waitUntil(), the page only needs to check if the commit succeeded if the sync event is still pending. (That is, the commit() could succeed but the "sync" event's transaction might not have committed through in the event of a crash.) > This is a really tricky case. The more I think about it, the more I think we should try to run success/complete/error handlers after a resume (if possible). If we don't, I can see lots of issue popping up. Speaking for Firefox's bfcache strategy, in situations like this we would usually either forbid the window (and the entire window hierarchy in which it lives) from going into bfcache because of ongoing activity or remove the window from the bfcache when it becomes semantically doomed. For example, we will forbid putting a window in bfcache if it has webrtc stuff going on or used WebVR, see [(nsIDocument::CanSavePresentation)](https://searchfox.org/mozilla-central/rev/8837610b6c999451435695e800f38d4acbc0a644/dom/base/nsDocument.cpp#8079). And we remove windows from bfcache if they receive a message via [BroadcastChannel or MessageChannel](https://searchfox.org/mozilla-central/search?q=RemoveDocFromBFCache&path=). Researching this led me to discover that we're buggy in the IDB case in exactly the way you fear here due to a longstanding regression, this is now [Gecko Bug 1458342](https://bugzilla.mozilla.org/show_bug.cgi?id=1458342). -- You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub: https://github.com/w3c/IndexedDB/issues/237#issuecomment-385775139
Received on Tuesday, 1 May 2018 20:09:32 UTC