Closed Bug 412080 Opened 17 years ago Closed 16 years ago

If session restored, and crashes, then Restore Session restores incorrectly

Categories

(Firefox :: Session Restore, defect)

x86
Windows XP
defect
Not set
normal

Tracking

()

VERIFIED INCOMPLETE

People

(Reporter: kyferez, Unassigned)

Details

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9b3pre) Gecko/2008011105 Minefield/3.0b3pre
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9b3pre) Gecko/2008011105 Minefield/3.0b3pre

If FF had crashed and you restore the session (I'll call this Session 1), it works fine. However if it crashes again and you restore the session again (I'll call this Session 2), it restores the Session 1 and you loose anything that was different from your session 2.

Reproducible: Always

Steps to Reproduce:
1. Open FF with a new session.
2. Open several tabs on different websites.
3. Get FF to crash (or goto task manager and kill firefox.exe)
4. Open FF again. Click Restore Previous Session.
5. Open new tabs and browse. Change the websites in existing tabs.
6. Get FF to crash again or end task again.
7. Open FF again. Click Restore Previous Session.
8. The new tabs are gone. The old tabs are on the wrong page.
Actual Results:  
Old session data restored

Expected Results:  
New session data should be restored.
Component: Startup and Profile System → Session Restore
QA Contact: startup → session.restore
do you see this in latest trunk version?
Mozilla/5.0 (Windows; U; Windows NT 5.1; de; rv:1.9pre) Gecko/2008051011 Minefield/3.0pre - Build ID: 2008051011

Confirming. Seeing this for the last couple of weeks. The old session gets restored, the new pages are still listed in the history database.

I'm off for the week, so don't expect responses or tests before saturday.

TravisG: Which extensions do you had installed?
Status: UNCONFIRMED → NEW
Ever confirmed: true
Keywords: qawanted
(In reply to comment #0)
> 5. Open new tabs and browse. Change the websites in existing tabs.

How long does this step take? If it's less than 10 seconds, then you're actually seeing the expected behavior and this bug is WORKSFORME.
(In reply to comment #4)
> Was hours or days for me.

Does that mean that if you wait only a few minutes, then the session is correctly restored? That would indicate that you've somehow been able to convince Firefox to think it's shutting down along the way when it really isn't (which might happen due to an extension or due to opening any of the secondary dialogs such as Downloads Manager, Add-ons Manager, Error Console, etc. inside a tab).

Maybe examining sessionstore.js can help: look if there are any chrome:// URLs listed in there and compare the file's last-modified date to how long into your browsing session it's actually been updated.
No, it restored the session from the session before that one I expected to get restored. Had rarely crashs in the past weeks, so can't reproduce.
Ok or not and maybe only related, had the bug today:
1. Session was killed by me after Shockwave caused a hang.
2. Started Firefox again, session restored as expected.
3. Get a hang like bug 41212, kill the application.
4. Start the application, nothing got restored.
5. Restored the session with Nightly Tester Tools: The same session like on the last restore has been created.

Hint: I see a useless AcroRd32.exe after the crash in the process list and am already convinced that it is worth to investigate if this is related to cause a hang or prevent the correct restore, but unfortunately I don't have the steps to reproduce.
(In reply to comment #7)
> 4. Start the application, nothing got restored.

Did you get the Session Restore prompt at all after the second crash?

> 5. Restored the session with Nightly Tester Tools: The same session like on the
> last restore has been created.

That just means that either sessionstore.bak wasn't overwritten/updated after the second crash or sessionstore.js was never updated between the two crashes.

A few questions for getting a clearer picture of the issue:
* How many windows did you have open at the time of the first/second crash?
* How long was Firefox open before it crashed the second time?
* Did you get any errors/messages in the Error Console after restarting Firefox after the second crash?
* Do you find any sessionstore-#.js files with a very recent last-modified date in your profile?
(In reply to comment #9)
> Did you get the Session Restore prompt at all after the second crash?
I don't remember about the crash I reported here, but I got the same problem again (memory increase and hang), killed Firefox, restored and then I got a window with a blank tab and a prompt for restoring the session. I did this, and now it was the session from 3 sessions ago.

> That just means that either sessionstore.bak wasn't overwritten/updated after
> the second crash or sessionstore.js was never updated between the two crashes.
> 
> A few questions for getting a clearer picture of the issue:
> * How many windows did you have open at the time of the first/second crash?
1
> * How long was Firefox open before it crashed the second time?
3 hours
> * Did you get any errors/messages in the Error Console after restarting Firefox
> after the second crash?
Seriously, I have always errors in the console and some extensions swamp it, so I can't tell you.
> * Do you find any sessionstore-#.js files with a very recent last-modified date
> in your profile?
There aren't any.

(In reply to comment #10)
Do sessionstore.js and sessionstore.bak get updated at all on your system (check the last-modified dates)? And am I right to assume that you always restore the session through the NTT menu item and not Firefox' own Session Restore dialog?
sessionstore.js 22:06
sessionstore.bak 19:08
They do at the moment.

There is also a session.rdf, last modified 19:15. Maybe extension related?

And no, I always let Firefox restore the session by telling it by the quit & restore prompt. I only use NTT if the session doesn't get restored (i.e. this happens if Firefox is launching and I click in a third party app).
(In reply to comment #12)
> There is also a session.rdf, last modified 19:15. Maybe extension related?

That'd be Tab Mix Plus which optionally provides its own session restoring facility. It could indeed be that TMP does interfere somehow with Session Restore. Only way to find out would be not to use TMP for a while...
Ah, found something: The session restore of TMP had been active, I don't know why. In Fx2 (>1/2 year ago), I already had the Fx2 build-in session restore in use. Invalid?
Yeah, TMP is quite a beast with occasionally unexpected consequences. Thanks for helping debug your issue. Now, before marking this bug WORKSFORME...

Travis: Could the Tab Mix Plus extension also have been responsible for your issue from comment #0?
Severity: major → normal
Keywords: qawanted
Closing as INCOMPLETE due to a missing response from Travis.

Travis: If this was indeed an issue with Tab Mix Plus, please close this bug as WORKSFORME, otherwise please REOPEN in case you want to help us debug the issue.
Status: NEW → RESOLVED
Closed: 16 years ago
Resolution: --- → INCOMPLETE
Status: RESOLVED → VERIFIED
You need to log in before you can comment on or make changes to this bug.