1894950 - Passing Blob to history.pushState silently kills the state when the tab is closed and reopened

Status: NEW

(Core :: DOM: Navigation, defect)

Description

[Kagami Rosylight [:saschanaz] (they/them)]

Bug 1189389 disallowed cloning DOM objects in GetDataAsBase64 and we still use that for session history in https://searchfox.org/mozilla-central/rev/386c7f17b2421374930a447c9f424910551b659d/toolkit/modules/sessionstore/SessionHistory.sys.mjs#303. Thus the behavior is:

1. Open https://example.com
2. pushState(new Blob(['foo'], undefined, '#blob'); on devtools
3. Close the tab (Ensure there's another tab so that this won't close the browser). This logs:

   JavaScript error: resource://gre/modules/sessionstore/SessionHistory.sys.mjs, line 303: NS_ERROR_FAILURE: Component returned failure code: 0x80004005 (NS_ERROR_FAILURE) [nsIStructuredCloneContainer.getDataAsBase64]

4. Restore the tab

Expected: There should be the corresponding navigation history, as on Chrome
Actual: It's gone.

Comment 1

[Kagami Rosylight [:saschanaz] (they/them)]

Session history sounds like very Olli thing, how should we proceed here? And is it good idea at all to store DOM objects outside of IndexedDB storage? (i.e. should this internally use IndexedDB?)

Comment 2

[Kagami Rosylight [:saschanaz] (they/them)]

Other serializable objects e.g. ImageData works as expected, so maybe we can just lift this limitation?

Edit: Actually not, my test for bug 1652063 crashes without that check 🙂

Comment 3

[Olli Pettay [:smaug][[e-mail]]]

Session store != session history.
Do you see issues with session history? Like pushState and then going back and accessing the state?
If not, then this is about session store and there is a separate component for that.
(and I know next to nothing about session store ;) )

Comment 4

[Kagami Rosylight [:saschanaz] (they/them)]

(In reply to Olli Pettay [:smaug][[e-mail]] from comment #3)

Session store != session history.
Do you see issues with session history? Like pushState and then going back and accessing the state?

Yes and no; it works as long as it's kept in memory as SessionHistory.sys.mjs (the file name!) holds it as nsIStructuredCloneContainer, and then the history item just disappears when you close and restore the tab as if pushState() never happened.

If not, then this is about session store and there is a separate component for that.

I only see Firefox Session Restore (which doesn't exactly have to do with pushState) and no Core component? It still may fit though.

Comment 5

[Olli Pettay [:smaug][[e-mail]]]

Firefox Session restore is the component yes.

Session History is implemented in .cpp and lives in docshell/* and it doesn't deal with restoring tabs or anything like that - it just tries to implement, well, session history :)

Comment 6

[Kagami Rosylight [:saschanaz] (they/them)]

I believe how to structure-clone-for-storage the data is more about .cpp area than JS, though. The current error stack being from JS is because of the way the session history implementation passes the data for lazy clone IMO.