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)

defect

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.
blocking2.0: --- → ?
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?
FWIW, private browsing uses the getBrowserState and setBrowserState session store APIs to save and restore the session(s).
Juan: can you get back to me about comment 1?
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
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!
(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.
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.
Ehsan, can you make sure that we are handling those events appropriately?
blocking2.0: ? → betaN+
Priority: -- → P2
Blocks: 598154
In belated response to comment #1: That is not the case. http://screencast.com/t/MThmYWMwMDct
I can reproduce this.  Investigating...
According to Ian, the patches in one of these bugs could have fixed this.
Depends on: 598795, 594644, 600665, 603721, 605935
So I tested things on a build with these patches applied, and it doesn't fix the problem.
No longer depends on: 594644, 598795, 600665, 603721, 605935
Ian, can you please explain to me what code is responsible for recreating the groups when nsISessionStore.setBrowserState is called?
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
Whiteboard: [4b4] → [4b4][waiting on bug 594644 to land on trunk]
Whiteboard: [4b4][waiting on bug 594644 to land on trunk] → [4b4][waiting on bug 594644 on trunk]
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.
This works for me now!
Status: NEW → RESOLVED
Closed: 13 years ago
Resolution: --- → WORKSFORME
Whiteboard: [4b4][waiting on bug 594644 on trunk] → [4b4]
Whiteboard: [4b4] → [4b4][softblocker]
Product: Firefox → Firefox Graveyard
You need to log in before you can comment on or make changes to this bug.