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
Wfm with 2002041111 (1.0.0 Branch)/ Win98SE.
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
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 ;)
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.
Still hoping someone will have time to look at this since it is affecting our product quality at OEone.
Assignee: jag → nobody
QA Contact: pmac → tabbed-browser
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
Last Resolved: 9 years ago
Resolution: --- → WORKSFORME
You need to log in before you can comment on or make changes to this bug.