581593 - about:sessionrestore forgets session data during upgrade to Firefox 4

Status: VERIFIED FIXED

(Firefox :: Session Restore, defect)

Description

[Henrik Skupin [:whimboo][⌚️UTC+1]]

Mozilla/5.0 (Windows; Windows NT 5.1; rv:2.0b2) Gecko/20100720 Firefox/4.0b2

Upgrading Firefox 3.6.x to Firefox 4.0 beta 2 after a crash state with the about:sessionrestore page open will cause the current session to get lost. It looks like that Minefield cannot read the session stored with Namoroka during the crash.

Steps:
1. Start Namoroka and use the task manager to kill it twice
2. Start Namoroka again to check that the session data is present
3. Start Minefield

With step 3 you can see that the complete session has been lost. No entry is shown in about:sessionrestore. Going back to Namoroka still shows the session.

Comment 1

[Paul O'Shannessy [:zpao] (not bugmail, email directly)]

Anything in the error console? Does this happen with 4.0b1 or is it new with b2?

Comment 2

[Henrik Skupin [:whimboo][⌚️UTC+1]]

Also happens for beta 1. So it exists a bit longer. Added regression keywords.

Comment 3

[Wayne Mery (:wsmwk)]

On Friday i mailed zpao with subject "4.0b2 testing" attached sessionstore.js session.js which was created with 3.7a 20100531. about:sessionrestore is blank and doesn't restore when clicking "restore".  In the past, when I've gotten blank (which was a long time ago) I was still able to restore.

But it's not an "always" issue - I've just restarted b2 after crashing and about:sessionstore looks fine.

Comment 4

[Dietrich Ayala (:dietrich)]

Comment 3 sounds like it's not reproducible anymore. If you see it again, please check the console for errors, and re-request blocking.

Comment 5

[Henrik Skupin [:whimboo][⌚️UTC+1]]

(In reply to comment #4)
> Comment 3 sounds like it's not reproducible anymore. If you see it again,
> please check the console for errors, and re-request blocking.

Comment 3 states that it only doesn't appear when you directly start Minefield directly after a crash happened.

I would assume that most people click restart in the crash reporter and reopen their Firefox 3.6.x version first before starting Firefox 4.0. In such a case the session is still lost with Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:2.0b3pre) Gecko/20100802 Minefield/4.0b3pre

There is no error displayed in the error console. I will try to get a testcase attached.

Comment 6

[Henrik Skupin [:whimboo][⌚️UTC+1]]

Attachment: sessionstore.js (testcase)

That was easy going. Simply put this sessionstore.js file into the profile folder and make sure that Firefox restores you last session on startup. You will see an empty list.

Comment 7

[Henrik Skupin [:whimboo][⌚️UTC+1]]

Attachment: sessionstore.js (diff)

Diff between a working and the failing sessionstore.js file.

Comment 8

[Mike Beltzner [:beltzner, not reading bugmail]]

Minusing for now, but very interested in this bug. I remember seeing it on some nightly updates, but it went away once I turfed my session. Is it possible this is a one-time bug?

Henrik, can you test the following?

 - Start with Firefox 3.5.* and 3.6.*
 - Build a session
 - upgrade to Firefox 4 Beta latest
 - see if the session sticks around

If you can confirm the bug that way, please renominate.

Comment 9

[Paul O'Shannessy [:zpao] (not bugmail, email directly)]

(In reply to comment #6)
> Created attachment 462112 [details]
> sessionstore.js (testcase)
> 
> That was easy going. Simply put this sessionstore.js file into the profile
> folder and make sure that Firefox restores you last session on startup. You
> will see an empty list.

So the error here is coming from JSON.parse in aboutSessionRestore.js - http://hg.mozilla.org/mozilla-central/file/tip/browser/components/sessionstore/content/aboutSessionRestore.js#l62

AHHHH OK. I see what's happening. We're restoring an about:sessionrestore page, which was in turn saving a session from Firefox 3.6. (Maybe this was explained properly before but I overlooked it).

The problem arises because the formdata saved (which holds the session) was not valid JSON because bug 387859 only happened on trunk. So the quick fix would be to do what we did there and catch the JSON.parse error & fallback to evalInSandbox - http://hg.mozilla.org/mozilla-central/file/38d4fdfa9fd7/browser/components/sessionstore/src/nsSessionStartup.js#l135

It's a pretty rare case, so that's probably OK.

Comment 10

[Paul O'Shannessy [:zpao] (not bugmail, email directly)]

So to be clear, I'm pretty sure this bug only occurs when you crash in Firefox 3.6, get about:sessionrestore open in 3.6, quit, then start Firefox 4.0.

Comment 11

[Paul O'Shannessy [:zpao] (not bugmail, email directly)]

Regression from bug 387859 (http://hg.mozilla.org/mozilla-central/rev/e3372af81a76)

Comment 12

[Paul O'Shannessy [:zpao] (not bugmail, email directly)]

Like I said, the fix should be trivial and since it's a potential upgrade issue, we should probably block on it (final, probably shouldn't prioritize for a beta)

Comment 13

[Dietrich Ayala (:dietrich)]

Per the latest comments, is a confirmed dataloss bug in migration - blocking+.

Comment 14

[Paul O'Shannessy [:zpao] (not bugmail, email directly)]

Attachment: Patch v0.1

Just takes the same logic used for falling back when parsing the file in nsSessionStartup. I also moved the triggering of the input event until after we make sure the string in the textbox is JSON.parse-able. It made the test easier to write (instead of looking for an error, just make sure we can parse the textbox's value)

Comment 15

[Dietrich Ayala (:dietrich)]

Comment on attachment 484103 [details] [diff] [review]
Patch v0.1

r=me, thanks Paul

Comment 16

[Paul O'Shannessy [:zpao] (not bugmail, email directly)]

Pushed http://hg.mozilla.org/mozilla-central/rev/c04353b79cfa

Comment 17

[Henrik Skupin [:whimboo][⌚️UTC+1]]

Verified fixed with Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:2.0b8pre) Gecko/20101027 Firefox/4.0b8pre