303715 - Opening a new tab will open it in the background/unselected briefly

Status: RESOLVED WORKSFORME

(Firefox :: Tabbed Browser, defect)

Description

[Ger Teunis]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8b4) Gecko/20050806 Firefox/1.0+
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8b4) Gecko/20050806 Firefox/1.0+

New tabs are created unselected first and rapidly selected after that.
Builds before 20050806 created new tabs directly, feeling a lot more snappy on
slower computers.


Reproducible: Always

Steps to Reproduce:
1. Open a new tab (middle clicking a link)
2. 
3.

Actual Results:  
The new tab is created unselected first then it is selected.

Expected Results:  
Like the builds before 20050806 did:
Create the new tab selected.

Comment 1

[Ria Klaassen (not reading all bugmail)]

First I could not reproduce it, but I see it now in ID:2005080722 and
ID:2005080801. Strangely not in ID:2005080703.

Comment 2

[Adam Guthrie]

Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9a1) Gecko/20050812 Firefox/1.0+
ID:2005081219

This was fixed by the last check-in for bug 249136.

Comment 3

[:Gavin Sharp [email: [e-mail]]]

Erm, no it wasn't. This is a symptom of the new method used to focus tabs, with
a setTimeout, and there isn't really much that can be done here other than
reverting the changes made in 249136. It makes opening new tabs seem slower, so
how that measures up against non-functioning scroll keys in certain windows is
the issue here. I suspect it's WONTFIX, but a non-setTimeout solution to bug
249136 would resolve this, and I hope that becomes possible at one point.

Comment 4

[Worcester12345]

(In reply to comment #3)
> ... a non-setTimeout solution to bug
> 249136 would resolve this, and I hope that becomes possible at one point.

Is there a bug open for that as a placeholder against 2.0? Thanks.

Comment 5

[:Gavin Sharp [email: [e-mail]]]

Bug 249136 was fixed correctly, it should be possible to back out the patch that
caused this.

Comment 6

[Aaron Leventhal]

Attachment: Unfortunately this actually breaks bug 249136

I'm posting this patch so people can play with it, even though it breaks bug
249136. I'm not sure why it's necessary for bug 249136, but perhaps the focus
controller change only really worked when this slight delay was also there.

Comment 7

[Ger Teunis]

I can't reproduce this anymore on the trunk builds.
Anyone able to confirm this is fixed?

Comment 8

[Adam Guthrie]

Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9a1) Gecko/20060712 Minefield/3.0a1

Same here. New tabs are selected pretty darn fast (if they're even being selected at all). ->WORKSFORME