Currently it is impossible for web developers to implement auto-saving on unloading a page, unless using localStorage (which is too limited), because all async operations may be canceled after beforeunload event. Background sync API doesn't help here because the apps have to save the data locally first before them can be sent to the cloud. Although apps can save data periodly, small data loss may still happen if they don't save on unloading.
So I suggest to introduce Promise type BeforeUnloadEvent.prototype.returnValue to allow auto-saving on unloading a page. Web developers can save data to IndexedDB during beforeunload event, and assign the resulting Promise to .returnValue:
document.onbeforeunload = ev => {
ev.returnValue = saveStateToDB();
};
When a UA finds that .returnValue is a Promise, it may turns the page to background (not visible to user but still alive) and wait for the Promise to be fulfilled, and then unload the page. If the Promise takes too long (say, 5s) to finish, UA may kill the page neverthless.
If this feature were implemented, the confirm dialog generated by beforeunload might become less useful and might be removed eventually.
Currently it is impossible for web developers to implement auto-saving on unloading a page, unless using localStorage (which is too limited), because all async operations may be canceled after
beforeunloadevent. Background sync API doesn't help here because the apps have to save the data locally first before them can be sent to the cloud. Although apps can save data periodly, small data loss may still happen if they don't save on unloading.So I suggest to introduce
PromisetypeBeforeUnloadEvent.prototype.returnValueto allow auto-saving on unloading a page. Web developers can save data to IndexedDB duringbeforeunloadevent, and assign the resulting Promise to.returnValue:When a UA finds that
.returnValueis aPromise, it may turns the page to background (not visible to user but still alive) and wait for thePromiseto be fulfilled, and then unload the page. If thePromisetakes too long (say, 5s) to finish, UA may kill the page neverthless.If this feature were implemented, the confirm dialog generated by
beforeunloadmight become less useful and might be removed eventually.