272474 - userChrome.css: If the Opacity for Tabs is Changed, Tabs in Non-Browser Windows Can be Switched Around

Status: RESOLVED WORKSFORME

(Firefox :: Tabbed Browser, defect)

Description

[Timothy P. Wolfe]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.5) Gecko/20041107 Firefox/1.0
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.5) Gecko/20041107 Firefox/1.0

If you have modified the opacity for tabs for all Firefox windows (via
userChrome.css), there is a bug when trying to switch between tabs in windows
other than the browser window.  When you switch between those tabs, some of them
will be switched around, and it will continue to do this for the next few tabs
that you switch between.  Eventually it will stop switching them around, and
(though they remain reordered) you can switch between them without them being
further switched around.  Closing the affected window and reopening it will put
the tabs back in their original order (and this process can be repeated).

The browser window itself does not have this problem, and you can switch between
tabs without them being switched around.

Reproducible: Always
Steps to Reproduce:
1. In your userChrome.css file, add the following lines (modify the value for
opacity if you want to; skip the @namespace line if you already have it in the
file):

@namespace url("http://www.mozilla.org/keymaster/gatekeeper/there.is.only.xul");

tab:not([selected="true"])
{opacity: 0.25 ! important;}

2. Open Firefox (or restart it, if it was open when modifying userChrome.css).
3. Open a few tabs (each with different pages) in the browser window, and switch
between them.
4. Open the "Page Info" window (or any non-browser window that has tabs visible).
5. Switch between a few of the tabs in that window.
Actual Results:  
When switching between tabs in the browser window, they will remain in the same
place, without being switched around.

When switching between tabs in non-browser windows, some of them will switch
places.  It will stop doing this after awhile, and you can switch between the
(reordered) tabs without them being further switched around.

If you close the affected window and then reopen it, the tabs will be back to
their original order (and this process can be repeated).

Expected Results:  
None of the tabs should have been moved around at all in those windows.

Comment 1

[Mike Connor [:mconnor]]

nothing in any of our code for tabbox really does moving, I'd suspect that you
have TBE installed.

Comment 2

[Dan M]

Personally I wouldn't touch TBE with a ten foot boathook -- I can't afford the
level of uncertainty it brings. Mike: please try it yourself. Really I'm
interested in whether you see it, too.

I'm confirming in Firefox 1.0 on WinXP. Restating the steps to reproduce a
/little/ more succintly:

1) Set opacity on all tab elements in userChrome.css,
   as stated in this bug's opening comment.
2) Launch Firefox. Tools Menu -> Page Info. See that the tabs appear to
   have their opacity set, as expected.
3) Click the "Links" tab.

Each tab you click may swap itself with another tab. It's something like
Pachinko: the tab swapping appears to follow a specific pattern that depends on
the order in which you click the tabs. Eventually all patterns seem to settle
down into a low-energy state and stay there. It's very bizarre and kind of neat.
Tabbed-browser tabs are unaffected.

Comment 3

[Timothy P. Wolfe]

Mike: I do not have TBE installed in my profile.  I have TB*P* installed, but
not TB*E*, due to what I've heard about what it can cause.

However, this problem could not have been caused by an extension, as I have been
able to reproduce this in a new profile, with only one modification: A
userChrome.css file containing only the lines I mentioned in the first message
of this bug.

Comment 4

[u88484]

tab:not([selected="true"])
{opacity: 0.25 ! important;}

Causes tabs to switch around but adding #content and they don't switch around anymore,

#content tab:not([selected="true"])
{opacity: 0.25 ! important;}


Donno why though.

Comment 5

[Rod Whiteley]

I'm seeing this in Firefox 1.5 (Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.8) Gecko/20051111 Firefox/1.5) and also in Sunbird (Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.9a1) Gecko/20051128 Mozilla Sunbird/0.3a1+).

It's disappointing that after a full year this seems to be no nearer resolution.

Comment 6

[Rod Whiteley]

Attachment: Test case using hbox

It looks like this is not specific to tabs or userChrome.css, but is related to the content tag in the binding.

Any node before the children causes the problem to appear--even a comment, although empty text nodes are OK.  Remove the node, and the problem goes away.  (In the case of tabs, the node before the children happens to be a spacer.)

The children do not actually move in the DOM.  They are just drawn wrongly.

Comment 7

[Rod Whiteley]

...and the problem does not appear if I view testcase.xul online, but if I save it and view the local copy the problem appears.

Comment 8

[James Ross]

This sounds just like the issues from bug 272646 and bug 261826, and may be all caused by bug 307394.

Comment 9

[Gregory Pappas [:gregp]]

Unable to reproduce