Closed
Bug 356050
Opened 18 years ago
Closed 16 years ago
crash during session restore causes some tabs to be blank upon restart
Categories
(Firefox :: Session Restore, defect)
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.
Comment 1•18 years ago
|
||
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.
Reporter | ||
Comment 2•18 years ago
|
||
(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.
Updated•18 years ago
|
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.
Updated•18 years ago
|
Component: Tabbed Browser → Session Restore
Updated•18 years ago
|
QA Contact: tabbed.browser → session.restore
Comment 4•18 years ago
|
||
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...
Comment 5•18 years ago
|
||
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.
Comment 6•17 years ago
|
||
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
Comment 7•17 years ago
|
||
Was this fixed as described in comment 6? (If so, I should probably report a new bug on a problem I'm seeing now...)
Comment 8•17 years ago
|
||
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
Comment 9•16 years ago
|
||
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: 16 years ago
Resolution: --- → DUPLICATE
You need to log in
before you can comment on or make changes to this bug.
Description
•