346307 - view problem with xul:stack widget

Status: RESOLVED DUPLICATE of bug 346035

(Core :: Web Painting, defect)

Description

[(not reading, please use [e-mail] instead)]

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")

Comment 1

[(not reading, please use [e-mail] instead)]

Attachment: [good] with the hbox at .5 opacity, here's what it is looks like when the bug is not happening (and clicks go to the toolbarbutton)

Comment 2

[(not reading, please use [e-mail] instead)]

Attachment: [bad] with the hbox at .5 opacity, here's what it is looks like when the bug is happening (and clicks go to the hbox)

Comment 3

[Joey Minta]

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.

Comment 4

[(not reading, please use [e-mail] instead)]

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

Comment 5

[(not reading, please use [e-mail] instead)]

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".

Comment 6

[Asaf Romano (gone)]

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

Comment 7

[(not reading, please use [e-mail] instead)]

> 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.

Comment 8

[(not reading, please use [e-mail] instead)]

> 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!

Comment 9

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

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 <
  >

Comment 10

[(not reading, please use [e-mail] instead)]

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...

Comment 11

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

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.

Comment 12

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

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.

Comment 13

[(not reading, please use [e-mail] instead)]

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.

Comment 14

[(not reading, please use [e-mail] instead)]

> 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.

Comment 15

[(not reading, please use [e-mail] instead)]

no longer blocking ff2.

will morph this into a core bug.

Comment 16

[(not reading, please use [e-mail] instead)]

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

Comment 17

[(not reading, please use [e-mail] instead)]

this is a dup, and roc has fixed it on the trunk.

*** This bug has been marked as a duplicate of 346035 ***