Closed Bug 625988 Opened 12 years ago Closed 12 years ago

tab groups merged after exiting private browsing

Categories

(Firefox Graveyard :: Panorama, defect, P2)

3.6 Branch
defect

Tracking

(blocking2.0 final+)

RESOLVED WORKSFORME
Tracking Status
blocking2.0 --- final+

People

(Reporter: dherman, Assigned: ttaubert)

References

Details

(Keywords: qawanted, Whiteboard: [hardblocker])

Attachments

(3 files)

Build Identifier: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:2.0b10pre) Gecko/20110114 Firefox/4.0b10pre

If you close your tab group in private browsing mode, then after exiting private browsing mode, existing tabs from multiple tab groups all get displayed together as if they were part of one single group.

Reproducible: Always

Steps to Reproduce:
1. Create more than one tab group in non-private mode, each with at least one tab.
2. Enter private browsing mode.
3. Close the current tab.
4. Exit private browsing mode.
Actual Results:
All tabs from multiple groups get showed together.

Expected Results:
Only the tabs from one group should be showed, or the zoomed-out Panorama screen.

Tested on a clean profile.

This may or may not be related to bug 624102?

Dave
Is this still occurring, or has bug 624102 fixed it?
Blocks: 627096
Priority: -- → P2
I just ran into this on x64 Win7. Activating Panorama puts them back in their homes.
OS: Mac OS X → All
Hardware: x86 → All
Woof. Never mind. I just tried it again (not being able to leave well enough alone, and all) and it's quite easy to have MUCH more unfortunate results. If you enter Panorama very swiftly after exiting PB, you get screenshot 1. 

The tabs positioning precludes you from drawing a group around them, forcing you to manually place your tabs back in their groups. After this is done (see screen shot 2) entering back into the tabbed browser still shows all of your tabs (screenshot 3), worse, there appears to be no way to get my tabbed browser to show the correct group.

I think this needs to block.
blocking2.0: --- → ?
Attached image Screenshot 1
Attached image screenshot 2
Attached image screenshot 3
Ian, are we still planning on blocking on this?
blocking2.0: ? → final+
Whiteboard: [hardblocker]
I haven't been able to reproduce this bug using the STRs in comment 0. Is it still happening? (with those or new STRs)
(In reply to comment #7)
> Ian, are we still planning on blocking on this?

I'm not in charge of blocking, but it seems pretty bad to me...
I could not be able to reproduce it as well.
It doesn't *seem* to be happening anymore with recent nightlies, at least not with the STR I reported. I'll try to see if I can reproduce some other way.

Dave
Tested original STR with clean and dirty profiles, couldn't reproduce.
Couldn't reproduce on Linux with trunk.
I am hoping that this is a dupe of bug 624727
Assignee: nobody → tim.taubert
Depends on: 624727
Mozilla/5.0 (Windows NT 6.1; rv:2.0b11pre) Gecko/20110127 Firefox/4.0b11pre

I was able to reproduce issue presented in Screenshot 1 using steps described in bug 624727.
OK, let's mark this as WORKSFORME, and make bug 624727 the blocker given that the STR no longer show this bug.
Status: NEW → RESOLVED
Closed: 12 years ago
Resolution: --- → WORKSFORME
Product: Firefox → Firefox Graveyard
You need to log in before you can comment on or make changes to this bug.