when pressing Ctrl+T, the second tab appear before the first, and the first tab is still active



17 years ago
9 years ago


(Reporter: atmjav, Unassigned)


Firefox Tracking Flags

(Not tracked)




17 years ago
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (Windows; U; Win98; en-US; rv:0.9.9+) Gecko/20020408
BuildID:    2002040803

In the late few builds when pressing Ctrl+T, the second tab appear before the
first, and the first tab is still active. (I expect it appearing at the end of
tabs, becoming active.)

Reproducible: Always

Comment 1

17 years ago
Wfm with 2002041111 (1.0.0 Branch)/ Win98SE.

Comment 2

17 years ago
It happens to me sometimes (cvs trunk linux 2002041200).
But I didn't find a way to reproduce it every time.
Ever confirmed: true
OS: Windows 98 → All

Comment 3

17 years ago
Can confirm this. It happens sometimes on my linux cvs builds (for some weeks
now). This is really annoying. The second tab is in the list before the first
tab and never shows an activated state even if it's page is displayed.
Additionally you cannot close the first tab. You have to close the second and
open it again, this mostly works. If I remember correctly further tabs are all
inserted before the first opened until you close them all except the first and
then open them again.

I too found no way of reproducing this when I want. It just happens always when
I don't want it ;)

Comment 4

17 years ago
I have seen this several times and have observed the following, if it is any help:

In tabbrowser.xml, method addTab, a <tab> is created and added to the <tabs>
element. The first time this method is called the created tab appears to be
missing its XBL properties, ( I tested this by invoking the 'label' property on
the tab ) without the XBL properties the 'selected' property is not called, so
the 'selected' attribute is not set, so it never appears active. 

On subsequent calls to addTab the new tab does have the 'selected' and 'label'

Also, this only happens if the XUL cache is ON. 

Comment 5

16 years ago
Still hoping someone will have time to look at this since it is affecting our
product quality at OEone.
Keywords: oeone
QA Contact: sairuh → pmac


11 years ago
Product: Core → SeaMonkey
Assignee: jag → nobody
QA Contact: pmac → tabbed-browser

Comment 6

10 years ago
This bug report is registered in the SeaMonkey product, but has been without a comment since the inception of the SeaMonkey project. This means that it was logged against the old Mozilla suite and we cannot determine that it's still valid for the current SeaMonkey suite. Because of this, we are setting it to an UNCONFIRMED state.

If you can confirm that this report still applies to current SeaMonkey 2.x nightly builds, please set it back to the NEW state along with a comment on how you reproduced it on what Build ID, or if it's an enhancement request, why it's still worth implementing and in what way.
If you can confirm that the report doesn't apply to current SeaMonkey 2.x nightly builds, please set it to the appropriate RESOLVED state (WORKSFORME, INVALID, WONTFIX, or similar).
If no action happens within the next few months, we move this bug report to an EXPIRED state.

Query tag for this change: mass-UNCONFIRM-20090614


9 years ago
Last Resolved: 9 years ago
Resolution: --- → WORKSFORME
You need to log in before you can comment on or make changes to this bug.