tab groups merged after exiting private browsing

RESOLVED WORKSFORME

Status

defect
P2
normal
RESOLVED WORKSFORME
9 years ago
3 years ago

People

(Reporter: dherman, Assigned: ttaubert)

Tracking

({qawanted})

Dependency tree / graph

Firefox Tracking Flags

(blocking2.0 final+)

Details

(Whiteboard: [hardblocker])

Attachments

(3 attachments)

Reporter

Description

9 years ago
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

Comment 2

9 years ago
I just ran into this on x64 Win7. Activating Panorama puts them back in their homes.
OS: Mac OS X → All
Hardware: x86 → All

Comment 3

9 years ago
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: --- → ?

Comment 4

9 years ago
Posted image Screenshot 1

Comment 5

9 years ago
Posted image screenshot 2

Comment 6

9 years ago
Posted image screenshot 3

Comment 7

9 years ago
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.
Reporter

Comment 11

9 years ago
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.

Comment 14

9 years ago
I am hoping that this is a dupe of bug 624727

Updated

9 years ago
Assignee: nobody → tim.taubert
Depends on: 624727

Comment 15

9 years ago
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: 9 years ago
Resolution: --- → WORKSFORME
Product: Firefox → Firefox Graveyard
You need to log in before you can comment on or make changes to this bug.