Closed Bug 356050 Opened 14 years ago Closed 12 years ago

crash during session restore causes some tabs to be blank upon restart

Categories

(Firefox :: Session Restore, defect)

2.0 Branch
x86
Linux
defect
Not set

Tracking

()

RESOLVED DUPLICATE of bug 367605

People

(Reporter: myk, Unassigned)

References

Details

(Keywords: dataloss)

Restarting after my computer abruptly shut down this morning, I told session restore to restore my previous session (about 25 tabs across two windows).  As it was doing so, Firefox crashed.

When I restarted Firefox, I again told session restore to restore my previous session, and it did so without crashing, but half the tabs in one of the windows were "Untitled" and blank.

Perhaps, during the first restart, session restore somehow recorded the current state of the tabs after opening them but before restoring my previous session to them.  Then, when I restarted, it saw my "previous session" as the one with a bunch of blank tabs.
Went all sites one page back? That would pretend Firefox from a loop of crashes. I have only seen this (going back) for Tab Mix Plus session restoring under 1.5.0.*, I believe.
(In reply to comment #1)
> Went all sites one page back?

Good question.  Unfortunately, I didn't look carefully enough to know whether it was possible to go back or forward in the Untitled tabs.
Component: Startup and Profile System → Tabbed Browser
Keywords: dataloss
QA Contact: startup → tabbed.browser
I consistently have the same problem [under linux and windows xp]
It appears that session restore is incrementally updating the session
state even while loading a previous one; thus, if it crashes before
all tabs are loaded, it will have saved a "blank" state.

Easy to reproduce --- create many open windows each with many open tabs.
Kill firefox.  Restart [and select restore], and while loading, kill firefox.
you will see the same behavior.

also, this can happen with more than simply blank tabs, but entire windows
will sometimes have all tabs listed as "(Untitled)" if that window had for
instance yet to load because a "Master Password" was being requested during
the crash.

Finally --- i would claim that the "session store" system should not
maintain a clear "this window/tab is loading" state, and not trash state
entries that are loading.  This would avoid this race condition problem.
Component: Tabbed Browser → Session Restore
QA Contact: tabbed.browser → session.restore
I've posted a patch to bug 367605 which should fix the "some tabs are restored blank" issue. A similar patch will still be needed for whole windows...
FF does indeed appear to save "blank tabs" session information when exiting while restoring (whether user-initiated or not).

Reproduction:
1. Turn on Session Restore At Startup.
2. Open up a bunch of tabs.
3. Exit Firefox normally.
4. Start Firefox.
5. While the tabs are still restoring/loading, exit Firefox.
6. Start Firefox.
Several tabs will now be restored to "(Untitled)" (blank page) instead of the web page that should be there.
Depends on: 367605
This bug should be fixed once the patches to bug 367605 (blank tabs) and bug 368676 (blank windows) are approved and checked in.
Depends on: 368676
No longer depends on: 368676
Was this fixed as described in comment 6?  (If so, I should probably report a new bug on a problem I'm seeing now...)
I just tried testing whether this still occurs on Firefox 3 Beta 2 by shutting down Firefox while the tabs are still being restored, but when I do this, the firefox.exe process doesn't die (disappears from the desktop, but remains in the Task Manager) and Firefox refuses to start again, saying I need to close the non-responding instance first. After killing FF with the Task Manager and restarting it, the saved tabs load normally.

Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9b2) Gecko/2007121120 Firefox/3.0b2
Please reopen, should this issue still occur even with bug 367605 being fixed.

For cross-reference: David filed bug 409129 for the issue in comment #7.
Status: NEW → RESOLVED
Closed: 12 years ago
Resolution: --- → DUPLICATE
Duplicate of bug: 367605
You need to log in before you can comment on or make changes to this bug.