Closed
Bug 137101
Opened 23 years ago
Closed 15 years ago
when pressing Ctrl+T, the second tab appear before the first, and the first tab is still active
Categories
(SeaMonkey :: Tabbed Browser, defect)
Tracking
(Not tracked)
RESOLVED
WORKSFORME
People
(Reporter: atmjav, Unassigned)
Details
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 2•23 years ago
|
||
It happens to me sometimes (cvs trunk linux 2002041200).
But I didn't find a way to reproduce it every time.
Status: UNCONFIRMED → NEW
Ever confirmed: true
OS: Windows 98 → All
Comment 3•23 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•23 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'
properties.
Also, this only happens if the XUL cache is ON.
Comment 5•22 years ago
|
||
Still hoping someone will have time to look at this since it is affecting our
product quality at OEone.
Keywords: oeone
Updated•22 years ago
|
QA Contact: sairuh → pmac
Assignee | ||
Updated•17 years ago
|
Product: Core → SeaMonkey
Updated•16 years ago
|
Assignee: jag → nobody
QA Contact: pmac → tabbed-browser
![]() |
||
Comment 6•16 years ago
|
||
MASS-CHANGE:
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
Status: NEW → UNCONFIRMED
Status: UNCONFIRMED → RESOLVED
Closed: 15 years ago
Resolution: --- → WORKSFORME
You need to log in
before you can comment on or make changes to this bug.
Description
•