1501594 - sessionStorage data cannot be restored anymore since Firefox 57

Status: RESOLVED WORKSFORME

(Firefox :: Session Restore, defect, P1)

Description

[baptx]

User Agent: Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:63.0) Gecko/20100101 Firefox/63.0

Steps to reproduce:

It looks like a bug has been introduced in Firefox 57 / Quantum and now when we close a tab, a window or the browser that has set a session storage item and restore the web page, the session storage item is not restored. I noticed that the last version that restored correctly a session storage item was Firefox 56 (tested on Linux 64-bit release). You can test the session storage here: https://www.w3schools.com/html/tryit.asp?filename=tryhtml5_webstorage_session

I also noticed a related problem that was already in versions before Firefox 57. On some websites, if we set a session storage item manually via the browser console and we close the tab, window or browser, when we restore the web page, the session storage item is restored correctly. However, in the browser console, in "Storage" tab, "Session Storage", if we right click on a session storage item and select "Delete All", the session storage item is deleted but when we close the tab, window or browser and restore the web page, the session storage item is restored even if it was deleted! (in fact, to really delete a session storage item in the browser console, we have to select "Delete <key_name>" instead of "Delete all" or execute sessionStorage.removeItem(<key_name>) in the browser console).


Actual results:

sessionStorage data cannot be restored anymore since Firefox 57.
It worked well on previous versions after another bug has been resolved (https://bugzilla.mozilla.org/show_bug.cgi?id=339445).


Expected results:

sessionStorage data should be restored if Firefox is restarted and is configured to restore the previous session or if we restore the session manually through Firefox menu (by pressing Alt key if it is hidden and selecting "Restore Previous Session").
sessionStorage data should also be restored if we restore a tab by pressing Ctrl+Shift+T or if we restore a window by pressing Ctrl+Shift+N.

Comment 1

[Dale Harvey (:daleharvey)]

If you could file a seperate bug for the "Delete All" issue and we could keep one open bug per issue that would be great cheers

Now if I open the console on this page and type |sessionStorage.hello = "world";| then close the browser + restore, I can see |sessionStorage.hello| when I reload. Can you try the same thing, is there any other symptoms or reason that you cant see sessionStorage being persisted, also trying on a more modern version would be great, thanks

Comment 2

[baptx]

To reproduce the issue, you should not execute JavaScript code manually in the browser console (this works correctly like I wrote) but you should visit a web page like https://www.w3schools.com/html/tryit.asp?filename=tryhtml5_webstorage_session that will execute the JavaScript code creating a sessionStorage item.

For the "Delete All" issue, I created a separate report but it looks like it has been fixed: https://bugzilla.mozilla.org/show_bug.cgi?id=1508150

Comment 3

[Mike de Boer [:mikedeboer]]

This looks like an issue very specific to w3schools and not Firefox. If Dale couldn't reproduce the issue, I think it's safe to close this as WFM.

Comment 4

[baptx]

No, the issue is not specific to W3Schools, you can test on other websites like JSFiddle: https://jsfiddle.net/baptx/nLcb5741
To reproduce the bug, the website has to execute the JavaScript code (instead of doing it manually in the browser console).
Please leave the issue open until it is fixed.

Comment 5

[Mike de Boer [:mikedeboer]]

baptx, thanks for adding additional information that might help us confirm the issue.

Dale, do you have time to take a look at this, then?

Comment 6

[Mike de Boer [:mikedeboer]]

I'm filing this under the reliability-tracking work to possibly be picked up when we're actively working on that theme. Doesn't seem like a blocker or critical issue.

Comment 7

[baptx]

For information, this issue can result in data loss or being disconnected from a website when closing the browser (accidentally or after a crash), which could be high / critical severity for a user.

Comment 8

[Warren Henning]

Is this still an issue? I made a JSFiddle where I invoke the counter function on load: https://jsfiddle.net/wpzgm0ne/ . I'm on Firefox 70.0.1, Windows 10.

On my machine, the counter increments as you refresh. If I'm understanding correctly, the sessionStorage appears to be working correctly and therefore this bug may have been resolved.

Comment 9

[baptx]

@Warren the issue is still here, I reproduced it on Firefox 71.0 64-bit Ubuntu Linux version with your example and mine too. If you click the button to change the value of the session storage, close the browser and restore the session, you will see that the value is not the same as before.

Comment 10

[Warren Henning]

Yeah, same on 71.0 Windows. Sorry for misunderstanding.

Comment 11

[Alphan Chen [:alchen]]

(In reply to Warren Henning from comment #8)

Is this still an issue? I made a JSFiddle where I invoke the counter function on load: https://jsfiddle.net/wpzgm0ne/ . I'm on Firefox 70.0.1, Windows 10.

On my machine, the counter increments as you refresh. If I'm understanding correctly, the sessionStorage appears to be working correctly and therefore this bug may have been resolved.

I use mozregression based on this example.
Based on the result, the regression is caused by the commit between 2017-08-02 and 2017-08-03.

8:57.58 INFO: Using local file: /tmp/tmp9t5zno/2017-08-02--mozilla-central--firefox-57.0a1.en-US.linux-x86_64.tar.bz2 (downloaded in background)
8:57.58 INFO: Running mozilla-central build for 2017-08-02
9:09.52 INFO: Launching /tmp/tmplFygk3/firefox/firefox
9:09.52 INFO: Application command: /tmp/tmplFygk3/firefox/firefox -profile /tmp/tmpUGq9HM.mozrunner
9:09.53 INFO: application_buildid: 20170802100302
9:09.53 INFO: application_changeset: 52285ea5e54c73d3ed824544cef2ee3f195f05e6
9:09.53 INFO: application_name: Firefox
9:09.53 INFO: application_repository: https://hg.mozilla.org/mozilla-central
9:09.53 INFO: application_version: 57.0a1
Was this nightly build good, bad, or broken? (type 'good', 'bad', 'skip', 'retry', 'back' or 'exit' and press Enter): good
9:49.55 INFO: Narrowed nightly regression window from [2017-08-01, 2017-08-03] (2 days) to [2017-08-02, 2017-08-03] (1 days) (~0 steps left)
9:49.55 INFO: Got as far as we can go bisecting nightlies...
9:49.55 INFO: Last good revision: 52285ea5e54c73d3ed824544cef2ee3f195f05e6 (2017-08-02)
9:49.55 INFO: First bad revision: 63e261ce8cb04c913d2e6b19ea451b7078d24dc1 (2017-08-03)
9:49.55 INFO: Pushlog:
https://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=52285ea5e54c73d3ed824544cef2ee3f195f05e6&tochange=63e261ce8cb04c913d2e6b19ea451b7078d24dc1

Comment 12

[Pablo]

I tried to reproduce this on windows10 and ubuntu 20 with the latest firefox release 93 and the issue is still happening.

Comment 13

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

In the process of migrating remaining bugs to the new severity system, the severity for this bug cannot be automatically determined. Please retriage this bug using the new severity system.

Comment 14

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

The severity field is not set for this bug.
:dao, could you have a look please?

For more information, please visit BugBot documentation.

Comment 15

[Sam Foster [:sfoster] (he/him)]

I'm not able to reproduce this. I've got a jsfiddle which retrieves a value from sessionStorage, and increments it when you click the button. This value seems to be correctly preserved and restored after a browser restart.

If I've misunderstood or you get a different result, please re-open this bug.

Comment 16

[Sam Foster [:sfoster] (he/him)]

Clearing need-info

Comment 17

[Sam Foster [:sfoster] (he/him)]

I want to double-check if the premise of this bug is incorrect or not. According to MDN, the sessionStorage object is intended to be cleared at the end of the page session. If the user closes the tab/page themselves the sessionStorage should not be retained. But in the case of a browser restart and session restore is the expectation that we seamlessly resume that session? In which case the current behavior is correct. Or that after a browser restart and session restore that the page and any form data are restored from the previous session, but sessionStorage is not.

Comment 18

[Dão Gottwald [:dao]]

(In reply to Sam Foster [:sfoster] (he/him) from comment #17)

If the user closes the tab/page themselves the sessionStorage should not be retained. But in the case of a browser restart and session restore is the expectation that we seamlessly resume that session?

Yes.