625988 - tab groups merged after exiting private browsing

Status: RESOLVED WORKSFORME

(Firefox Graveyard :: Panorama, defect, P2)

Description

[Dave Herman [:dherman]]

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

Comment 1

[Ian Gilman [:iangilman]]

Is this still occurring, or has bug 624102 fixed it?

Comment 2

[Kevin Hanes]

I just ran into this on x64 Win7. Activating Panorama puts them back in their homes.

Comment 3

[Kevin Hanes]

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.

Comment 4

[Kevin Hanes]

Attachment: Screenshot 1

Comment 5

[Kevin Hanes]

Attachment: screenshot 2

Comment 6

[Kevin Hanes]

Attachment: screenshot 3

Comment 7

[Sheila Mooney]

Ian, are we still planning on blocking on this?

Comment 8

[:Felipe Gomes (needinfo for replies!)]

I haven't been able to reproduce this bug using the STRs in comment 0. Is it still happening? (with those or new STRs)

Comment 9

[Ian Gilman [:iangilman]]

(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...

Comment 10

[Raymond Lee [:raymondlee]]

I could not be able to reproduce it as well.

Comment 11

[Dave Herman [:dherman]]

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

Comment 12

[Dietrich Ayala (:dietrich)]

Tested original STR with clean and dirty profiles, couldn't reproduce.

Comment 13

[Tim Taubert [:ttaubert] (inactive)]

Couldn't reproduce on Linux with trunk.

Comment 14

[Kevin Hanes]

I am hoping that this is a dupe of bug 624727

Comment 15

[George Carstoiu]

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.

Comment 16

[Shawn Wilsher :sdwilsh]

OK, let's mark this as WORKSFORME, and make bug 624727 the blocker given that the STR no longer show this bug.