First tab in stack changes when expand button is opened and then closed

VERIFIED FIXED in Firefox 4.0b12

Status

defect
P3
normal
VERIFIED FIXED
9 years ago
3 years ago

People

(Reporter: george.carstoiu, Assigned: raymondlee)

Tracking

unspecified
Firefox 4.0b12
x86
All
Dependency tree / graph
Bug Flags:
in-testsuite +

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(1 attachment, 2 obsolete attachments)

Reporter

Description

9 years ago
User-Agent:       Mozilla/5.0 (Windows NT 5.1; rv:2.0b9pre) Gecko/20110106 Firefox/4.0b9pre
Build Identifier: Mozilla/5.0 (Windows NT 5.1; rv:2.0b9pre) Gecko/20110106 Firefox/4.0b9pre

By opening and closing the stacked list with tabs, using the expand button, the first tab from the pile changes to the first tab present in tab view.


Reproducible: Always

Steps to Reproduce:
1.Open at least three websites in same group (ex: www.google.com, www.nasa.gov, www.cnn.com)
2.Go to Panorama and minimize group until you get stacked pile.
3.Press expand button and select www.nasa.gov
4.Go to Panorama and observe stacked pile (nasa.gov should be the first tab)
5.Press expand button
6.Dismiss opened window

Actual Results:  
First tab from tab view (www.google.com) is shown as first tab in pile.


Expected Results:  
Previous accessed window is shown as first in pile (our case nasa.gov).

Also, when switching for the first time from tab view to panorama and minimizing in order to obtain the stack, the first tab in the pile is not the last accessed one (in the above example www.nasa.gov).
Would this improve/be fixed by bug 616729, which should better enforce that the tab order in groups (and therefore which tab is the topmost in a stack) better sync the real tab order?
Reporter

Updated

9 years ago
Status: UNCONFIRMED → NEW
Ever confirmed: true
Blocks: 627096
Priority: -- → P3
Bug 616729 has now landed; can you see if this is still happening, George?
Reporter

Comment 3

9 years ago
Mozilla/5.0 (Windows NT 6.1; rv:2.0b11pre) Gecko/20110127 Firefox/4.0b11pre

I can still reproduce the issue.
Assignee

Updated

9 years ago
Assignee: nobody → raymond
Status: NEW → ASSIGNED
Assignee

Comment 4

9 years ago
Posted patch v1 (obsolete) — Splinter Review
Attachment #510235 - Flags: review?(ian)
Comment on attachment 510235 [details] [diff] [review]
v1

In addition to removing the topChild = null from _gridArrange(), you need to add a topChild = null to arrange() right before it calls _gridArrange(). topChild is supposed to be relatively temporary, and shouldn't survive a group getting unstacked (though I'm fine with it surviving expand/collapse).

Otherwise looks good.
Attachment #510235 - Flags: review?(ian) → review-
Assignee

Comment 6

9 years ago
Posted patch v1 (obsolete) — Splinter Review
(In reply to comment #5)
> Comment on attachment 510235 [details] [diff] [review]
> v1
> 
> In addition to removing the topChild = null from _gridArrange(), you need to
> add a topChild = null to arrange() right before it calls _gridArrange().
> topChild is supposed to be relatively temporary, and shouldn't survive a group
> getting unstacked (though I'm fine with it surviving expand/collapse).
> 
Put topChild = null right before it calls _gridArrange() would simply bring back the bug.  I've moved the topChild = null to the else block in _gridArrange() so topChild would get cleared when a group is not stacked.
Attachment #510235 - Attachment is obsolete: true
Attachment #510500 - Flags: review?(ian)
Comment on attachment 510500 [details] [diff] [review]
v1

Good call
Attachment #510500 - Flags: review?(ian) → review+
Assignee

Updated

9 years ago
Attachment #510500 - Flags: approval2.0?
Raymond, please make sure that this bug doesn't make the bug 633074 regression worse... just want to make sure, as this touches similar code paths.
Assignee

Comment 9

9 years ago
(In reply to comment #8)
> Raymond, please make sure that this bug doesn't make the bug 633074 regression
> worse... just want to make sure, as this touches similar code paths.

I am certain that it would make the bug 633074 regression worse.
Assignee

Comment 10

9 years ago
(In reply to comment #9)
> (In reply to comment #8)
> > Raymond, please make sure that this bug doesn't make the bug 633074 regression
> > worse... just want to make sure, as this touches similar code paths.
> 
> I am certain that it would make the bug 633074 regression worse.

Oops! I mean it would not.
(In reply to comment #10)
> (In reply to comment #9)
> > (In reply to comment #8)
> > > Raymond, please make sure that this bug doesn't make the bug 633074 regression
> > > worse... just want to make sure, as this touches similar code paths.
> > 
> > I am certain that it would make the bug 633074 regression worse.
> 
> Oops! I mean it would not.

lol good. That's what I thought. :)
Comment on attachment 510500 [details] [diff] [review]
v1

low footprint, has tests, improves behavioral consistency in Panorama -> a+
Attachment #510500 - Flags: approval2.0? → approval2.0+
Attachment #510500 - Attachment is obsolete: true

Comment 15

9 years ago
http://hg.mozilla.org/mozilla-central/rev/de0d135053fc
Status: ASSIGNED → RESOLVED
Closed: 9 years ago
Flags: in-testsuite+
Keywords: checkin-needed
Resolution: --- → FIXED
Target Milestone: --- → Firefox 4.0b12
Reporter

Comment 16

9 years ago
Mozilla/5.0 (Windows NT 6.1; rv:2.0b12pre) Gecko/20110215 Firefox/4.0b12pre

Issue no longer present.
Status: RESOLVED → VERIFIED
Product: Firefox → Firefox Graveyard
You need to log in before you can comment on or make changes to this bug.