after a certain point, the "all tabs" menu button will stop opening (and will look wrong during animation) "I haven't figure out how to reproduce this, but at least twice now I am seeing a weird issue. the issue is that the button appears as if the opacity of the toolbarbutton is 1.0 (instead of the .999 that I've set in browser.css) domi tells me that it's still .999, but visually, it looks like it looks when it is 1.0" I still don't know what causes it, but I have confirmed that when I'm in this state, the clicks go into the bottom stack element. roc writes: "I guess the frames are in the wrong order". Is there something that could cause the frames to change order? in my case, i have the hbox and the toolbarbutton in my <stack>. the opacity of the hbox varies from 0.0,0.1,0.2...0.9,1.0 but the opacity of the toolbarbutton stays at 0.999. I'll attach a screen shot to indicate what I mean by it "looks wrong during animation")

I'm wondering if certain computations round .999 up to 1.0, but others don't, causing the mixed behavior here. That's the only explanation I can think of for why moving from .99 to .999 would have been a workaround for some of the related bugs here.

I think having this button (a new feature) stop working could block ff2.

joey: I'll try using .99 (instead of .999) for the opacity of the toolbarbutton (in browser.css) but, to be clear, .999 works for a certain about of time, and then stops working (I'm still unsure what triggers it to stop.) my uneducated guess is that perhaps it is related to this comment from roc: "I guess the frames are in the wrong order".

Seth, why is this filed separately, the patch for bug 346035 isn't even on trunk right now...

> I'll try using .99 (instead of .999) for the opacity of the toolbarbutton (in browser.css) fwiw, using .9 (in browser.css) still got me into a state where (after a while, still not sure what causes it yet) the hbox takes the clicks.

> Seth, why is this filed separately, the patch for bug 346035 isn't even on > trunk right now... I filed it separately, to keep track of this issue and to alert bz and roc about this related problem with stacks and opacity. additionally, I like to use bugzilla to track everything!

So I saw the view tree originally look like this: 0x93c2668 {9948,1188,420,336} z=0 vis=1 opc=0.999 tran=1 clientData=0x93be8f8 < > 0x98b3428 {9948,1188,420,336} z=0 vis=1 opc=0.000 tran=0 clientData=0x93be718 < > and then after seeing the bug, the second view there (the orange box) got removed from the view tree and a new view created so that it was very early in the list (and thus presumably on top): 0x99c3200 {9948,1188,420,336} z=0 vis=1 opc=0.000 tran=0 clientData=0x93be718 < > ... 0x93c2668 {9948,1188,420,336} z=0 vis=1 opc=0.999 tran=1 clientData=0x93be8f8 < >

david suggests the following: instead of setting the opacity of the hbox to 1.00 in my animation loop, set it to 0.99. trying that out now...

The reason I suggested that is that nsStyleDisplay::CalcDifference won't cause a frame reconstruct. But what I don't understand is why the behavior is inconsistent. What I was thinking is that there's code to make sure the view gets reinserted in the right point that was failing sometimes. However, when I see the bug I'm seeing a new view created each new tab, end when I'm not seeing the bug I see the same view pointers after creating a new tab.

FWIW, I'd think this bug is 1.8 branch only (and older), since views are no longer important enough to cause this and will sometime soon be removed completely.

dbaron gave me a trick that appears to solve this issue! it involves wrapping the children of the stack with <xul:hbox flex="1" style="position: relative;">...</xul:hbox> I no longer have to use the opacity: 0.99 fix, and so far, I have not run into this bug. by using position relative, it forces each child to have their own view (according to dbaron), which solves the problem.

> it involves wrapping the children of the stack > with <xul:hbox flex="1" style="position: relative;">...</xul:hbox> to be 100% correct, the flex="1" goes on the child of the hbox. I'm going to keep this bug open, and morph it to cover 1) remove the <xul:hbox style="position: relative;">...</xul:hbox> hack from tabbrowser.xml 2) cover the underlying problem that his hack works around. thanks again to dbaron for suggesting this trick.

no longer blocking ff2. will morph this into a core bug.

I'm guessing, from what david wrote, that this is core : layout view rendering bug?

this is a dup, and roc has fixed it on the trunk. *** This bug has been marked as a duplicate of 346035 ***