Closed
Bug 588597
Opened 14 years ago
Closed 13 years ago
tab set interaction with private browsing mode can make tabs appear and reappear from tab strip
Categories
(Firefox Graveyard :: Panorama, defect, P2)
Firefox Graveyard
Panorama
Tracking
(blocking2.0 betaN+)
RESOLVED
WORKSFORME
Tracking | Status | |
---|---|---|
blocking2.0 | --- | betaN+ |
People
(Reporter: jbecerra, Assigned: ehsan.akhgari)
References
Details
(Whiteboard: [4b4][softblocker])
While testing Fx4b4 (build2), the interaction between tab sets and private browsing mode, can be very confusing: I opened several tabs, enough to overflow the strip. Then I went into tab set view, and I selected one of the tabs and dragged it out of its group, then I clicked on it which took me out of the tab set view. When I toggle PB mode in this case, the latter tab is "re-attached" to the tab strip. And If I shift-reload that tab, and click on the tab strip drop down menu, it disappears! Going back to tab set view will show the missing tab, but it can be really confusing, nearly scary.
Reporter | ||
Updated•14 years ago
|
blocking2.0: --- → ?
Comment 1•14 years ago
|
||
Juan, trying to unpack your report here: - have a bunch of tabs - invoke the overview of tabs in tabcandy and see all tabs in group "A" - create a new group "B" with a single tab from group "A" - select this new tab from group "B" - you now have a single tab on the tabstrip - enter Private Browsing At this point, you should have no tabs other than the welcome to private browsing one. TabCandy should also be empty. When you restore out of PB mode, I'd expect you to be dropped back onto the single tab as the window is viewing group "B". The overview should show groups A and B. Is that not the case?
Assignee | ||
Comment 2•14 years ago
|
||
FWIW, private browsing uses the getBrowserState and setBrowserState session store APIs to save and restore the session(s).
Comment 4•14 years ago
|
||
It appears that we do not correctly restore groups after returning from Private Browsing mode. It does seem like the position of the tabs is correct, just that their groups don't seem to be recreating. My guess is that we do not correctly save group information before entering Private Browsing mode?
Assignee: nobody → ehsan
OS: Mac OS X → All
Hardware: x86 → All
Comment 5•14 years ago
|
||
I believe (but do not know for sure!) that we use session restore there, so not sure why we wouldn't be saving the tabcandy info before entering PB mode. Adding zpao the invincible!
Comment 6•14 years ago
|
||
(In reply to comment #5) > I believe (but do not know for sure!) that we use session restore there, so not > sure why we wouldn't be saving the tabcandy info before entering PB mode. > Adding zpao the invincible! It is purely speculation on my part that we have yet to write that information out to session storage.
Comment 7•14 years ago
|
||
We do use session restore. What I don't know is how TC is handling the PB mode change. There are observer topics that can be listened for (private-browsing-cancel-vote, private-browsing, private-browsing-transition-complete). Session restore doesn't inherently know anything about TC state (just extra data until we have bug 588217). So if TC wants to read/write data from session restore pre/post-pb transition, it needs to do that on it's own.
Comment 8•14 years ago
|
||
Ehsan, can you make sure that we are handling those events appropriately?
Updated•14 years ago
|
blocking2.0: ? → betaN+
Updated•14 years ago
|
Priority: -- → P2
Reporter | ||
Comment 11•14 years ago
|
||
In belated response to comment #1: That is not the case. http://screencast.com/t/MThmYWMwMDct
Assignee | ||
Comment 12•14 years ago
|
||
I can reproduce this. Investigating...
Assignee | ||
Comment 13•14 years ago
|
||
According to Ian, the patches in one of these bugs could have fixed this.
Assignee | ||
Comment 14•14 years ago
|
||
So I tested things on a build with these patches applied, and it doesn't fix the problem.
Assignee | ||
Comment 15•14 years ago
|
||
Ian, can you please explain to me what code is responsible for recreating the groups when nsISessionStore.setBrowserState is called?
Comment 16•14 years ago
|
||
At the very least, we need bug 594644 to land before we can debug this. Other bugs that may possibly affect this area are bug 603721 and 605935.
Depends on: 594644
Assignee | ||
Updated•14 years ago
|
Whiteboard: [4b4] → [4b4][waiting on bug 594644 to land on trunk]
Assignee | ||
Updated•14 years ago
|
Whiteboard: [4b4][waiting on bug 594644 to land on trunk] → [4b4][waiting on bug 594644 on trunk]
Comment 17•13 years ago
|
||
At long last, bug 594644 has landed! Ehsan, please see if this bug still exists now. If it does, you're clear to start work on it.
Assignee | ||
Comment 18•13 years ago
|
||
This works for me now!
Status: NEW → RESOLVED
Closed: 13 years ago
Resolution: --- → WORKSFORME
Assignee | ||
Updated•13 years ago
|
Whiteboard: [4b4][waiting on bug 594644 on trunk] → [4b4]
Updated•13 years ago
|
Whiteboard: [4b4] → [4b4][softblocker]
Updated•8 years ago
|
Product: Firefox → Firefox Graveyard
You need to log in
before you can comment on or make changes to this bug.
Description
•