Closed
Bug 400873
Opened 17 years ago
Closed 17 years ago
State of history sidebar not saved correctly
Categories
(Firefox :: Session Restore, defect, P3)
Firefox
Session Restore
Tracking
()
VERIFIED
FIXED
Firefox 3 beta3
People
(Reporter: reed, Assigned: zeniko)
References
Details
(Keywords: regression)
So, sometime during my session, I opened the history sidebar to get something. I most likely crashed while the sidebar was open, so when I did a session restore, the history sidebar came back. Sure, that's all fine and dandy. The problem is that after I restore and close the sidebar, if I crash again and have to do a session restore, the history sidebar comes back! It's like session restore doesn't notice that I had closed it and keeps trying to bring it back every time I restore. I can reproduce this quite regularly with my current session. If I make sure I don't have the history sidebar open, let Firefox sit for a bit while I do other stuff in order to make sure it saves a session, and then `killall -9 firefox-bin` to force close, the next restore will still have the history sidebar open. ;( I'm not sure if this is just for the history sidebar. It could affect other sidebars, too, but I can confirm it at least affects history sidebar.
Comment 1•17 years ago
|
||
closing with the [X] button, or ctrl+H ?
Reporter | ||
Comment 2•17 years ago
|
||
[X] button
Comment 3•17 years ago
|
||
does it also happen if you use ctrl+H to hide the sidebar ?
Assignee | ||
Comment 4•17 years ago
|
||
(In reply to comment #0) > If I make sure I don't have the history sidebar open, let Firefox sit > for a bit while I do other stuff in order to make sure it saves a session, What kind of "other stuff"? Just letting Firefox sit there won't trigger a save operation, you'll at least have to switch tabs first. In case you do that: what do you find in sessionstore.js when searching for "sidebar:" (without the quotes) after the first/second crash? Does it read sidebar:"" (i.e. no sidebar should be opened) or is the value still set after crash #2?
Updated•17 years ago
|
OS: Linux → All
Hardware: PC → All
Assignee | ||
Comment 5•17 years ago
|
||
Regression due to "tweaks 2" from bug 398807. We really never clear the sidebar state anymore... at all.
Keywords: regression
Comment 6•17 years ago
|
||
(In reply to comment #0) > I'm not sure if this is just for the history sidebar. It could affect other > sidebars, too, but I can confirm it at least affects history sidebar. > FWIW, I hit the same situation with the bookmark sidebar last night using Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9b2pre) Gecko/2007111923 Minefield/3.0b2pre ID:2007111923
Reporter | ||
Updated•17 years ago
|
Flags: blocking-firefox3?
Updated•17 years ago
|
Assignee: nobody → dietrich
Priority: -- → P3
Target Milestone: --- → Firefox 3 M11
Updated•17 years ago
|
Flags: blocking-firefox3? → blocking-firefox3+
Reporter | ||
Comment 7•17 years ago
|
||
There's a patch in bug 407166 to fix this.
Reporter | ||
Comment 8•17 years ago
|
||
zeniko's patch in bug 407166 supposedly fixed this. I'll reopen if I see it again.
Assignee: dietrich → zeniko
Reporter | ||
Updated•17 years ago
|
Updated•17 years ago
|
Flags: in-litmus?
Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9) Gecko/2008052906 Firefox/3.0 Doesn't seem to reoccur in XP. I kill FF and it starts up just fine.
Comment 10•16 years ago
|
||
Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9) Gecko/2008060309 Firefox/3.0 Verified dozens of times. Noticed sometimes the sidebar state (open/closed) was not restored until after next crash, but only when using the "X" button. For Ctrl+H it seemed to work fine constantly. However, in no way did I manage to get it stuck open or closed for good which means this is fixed :)
Status: RESOLVED → VERIFIED
Comment 11•16 years ago
|
||
https://litmus.mozilla.org/show_test.cgi?id=5874 added to Litmus.
Flags: in-litmus? → in-litmus+
You need to log in
before you can comment on or make changes to this bug.
Description
•