Closed
Bug 346035
Opened 18 years ago
Closed 18 years ago
with <stack> of two elements, if bottom element has opacity != 100% there are event / rendering problems
Categories
(Core :: XUL, defect)
Tracking
()
VERIFIED
FIXED
People
(Reporter: moco, Assigned: roc)
References
Details
(Keywords: testcase)
Attachments
(5 files, 1 obsolete file)
749 bytes,
application/vnd.mozilla.xul+xml
|
Details | |
16.25 KB,
image/png
|
Details | |
21.38 KB,
image/tiff
|
Details | |
51.80 KB,
image/tiff
|
Details | |
8.55 KB,
patch
|
dbaron
:
review+
dbaron
:
superreview+
|
Details | Diff | Splinter Review |
with <stack> of two elements, if bottom element has opacity != 100% there are event / rendering problems. specifically: 1) the bottom element gets the clicks, instead of the top element 2) the bottom element is drawn on top of the top element. see the attached simplified test case and screen shot. (this came from bug #342900)
Reporter | ||
Comment 1•18 years ago
|
||
Reporter | ||
Comment 2•18 years ago
|
||
Reporter | ||
Comment 3•18 years ago
|
||
in that screen shot, I clicked on the middle button ("test 2") the alert should say "test 2 button", but it says "test 2 box" as the event is going to the box. also notice that the button is red (at %50). only the border should be, which demonstrates that the box is drawn "on top" of the button.
Comment 4•18 years ago
|
||
Likely view related. roc did a lot of work in this area for 1.9 so he may know what is going on.
Comment 5•18 years ago
|
||
Not sure what it is but I think there is some relationship here with bug 317125
Reporter | ||
Comment 6•18 years ago
|
||
bz and mconnor just discovered a workaround! set the opacity of the button to .999 and it works as expected (trunk and branch)
Comment 7•18 years ago
|
||
Is this even an issue on trunk? This looks like a dup of one of the deps of bug 317375....
Reporter | ||
Comment 8•18 years ago
|
||
> Is this even an issue on trunk? This looks like a dup of one of the deps of
> bug 317375....
the attached test case has the same problem on my recent trunk windows xp build as it does on the branch.
Comment 9•18 years ago
|
||
So I also see a problem with stack #1 -- the painting is right, but the box is getting click events... For stack 2, here's what the display lists look like: Painting --- before optimization (dirty 0,0,1414,490): SolidColor 0x83e1ca8(Viewport(-1)) (0,0,1414,490) Background 0x83e1d3c(RootBox(window)(-1)) (0,0,1414,490) opaque uniform Background 0x83e20a0(DocElementBox(window)(-1)) (0,0,1414,490) Clip (nil)() (0,0,1414,490) Background 0x8489fb4(ButtonBoxFrame(button)(1)) (70,14,1260,448) Border 0x8489fb4(ButtonBoxFrame(button)(1)) (70,14,1260,448) XULTextBox 0x848a438(TextBox(label)(-1)[value=test 2]) (448,98,490,266) Clip 0x8489d00(Box(box)(0)) (0,0,1414,490) WrapList 0x8489d00(Box(box)(0)) (0,0,1400,490) Opacity 0x8489d00(Box(box)(0)) (0,0,1400,490) Background 0x8489d00(Box(box)(0)) (0,0,1400,490) opaque uniform Painting --- after optimization: Background 0x83e1d3c(RootBox(window)(-1)) (0,0,1414,490) opaque uniform Background 0x83e20a0(DocElementBox(window)(-1)) (0,0,1414,490) Clip 0x8489d00(Box(box)(0)) (0,0,1414,490) Background 0x8489fb4(ButtonBoxFrame(button)(1)) (70,14,1260,448) Border 0x8489fb4(ButtonBoxFrame(button)(1)) (70,14,1260,448) XULTextBox 0x848a438(TextBox(label)(-1)[value=test 2]) (448,98,490,266) Opacity 0x8489d00(Box(box)(0)) (0,0,1400,490) Background 0x8489d00(Box(box)(0)) (0,0,1400,490) opaque uniform Even before optimization, things seem to be in the wrong order, no? roc?
Assignee | ||
Comment 10•18 years ago
|
||
Yes, they're in the wrong order. nsStackFrame::BuildDisplayListForChildren looks OK. I guess the frames are in the wrong order. I'll look into it.
Reporter | ||
Comment 11•18 years ago
|
||
roc / bz / et al: in bug #342900 I reported: "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.
Blocks: 342900
Reporter | ||
Comment 12•18 years ago
|
||
I've spun out the "after a certain point, the .999 opacity trick stops working" to bug #346307.
Reporter | ||
Comment 13•18 years ago
|
||
another workaround, per dbaron: it involves wrapping the children of the stack with <xul:hbox flex="1" style="position: relative;">...</xul:hbox>
the flex goes on the child of the wrapping box, but yeah.
(In reply to comment #10) > Yes, they're in the wrong order. nsStackFrame::BuildDisplayListForChildren > looks OK. I guess the frames are in the wrong order. I'll look into it. Do pseudo-stacking-contexts contain real stacking contexts properly? If not, then I don't think it looks right -- and that matches my observations of the behavior.
Reporter | ||
Comment 16•18 years ago
|
||
> the flex goes on the child of the wrapping box, but yeah.
my apologies for being sloppy. I'm doing the following in tabbrowser.xml
<xul:hbox style="position: relative;">
<xul:hbox flex="1" class="tabs-alltabs-box" anonid="alltabs-box"/>
</xul:hbox>
<xul:hbox style="position: relative;">
<xul:toolbarbutton class="tabs-alltabs-button" type="menu">
<xul:menupopup class="tabs-alltabs-popup"
anonid="alltabs-popup"
position="after_end"/>
</xul:toolbarbutton>
Reporter | ||
Comment 17•18 years ago
|
||
Reporter | ||
Comment 18•18 years ago
|
||
Assignee | ||
Comment 19•18 years ago
|
||
(In reply to comment #15) > (In reply to comment #10) > > Yes, they're in the wrong order. nsStackFrame::BuildDisplayListForChildren > > looks OK. I guess the frames are in the wrong order. I'll look into it. > > Do pseudo-stacking-contexts contain real stacking contexts properly? No, but that's not quite what's happening here... > If not, > then I don't think it looks right -- and that matches my observations of the > behavior. You're right. The problem is not the frame order. The problem is that the <stack> treats the child button as a pseudo-stacking-context, which (not being positioned) goes in the Content list, but the child box is a true stacking context so it gets put in the PositionedDescendants list, above the button. I'm not 100% sure what the right behaviour for <stack> should be, but it seems people are expecting it to treat each child as a true stacking context.
My initial guess at correct behavior would be a true stacking context that puts itself in to the Block or Inline list (not PositionedDescendants like most do).
Assignee | ||
Comment 21•18 years ago
|
||
This forces each child into its own true stacking context which gets put on the Content() list of the <stack>.
Assignee: jag → roc
Status: NEW → ASSIGNED
Attachment #231569 -
Flags: superreview?(dbaron)
Attachment #231569 -
Flags: review?(dbaron)
What makes it go on Content() rather than PositionedDescendants? Other than that, this seems fine.
Assignee | ||
Comment 23•18 years ago
|
||
I don't know why I thought they were going into the PositionedDescendants list. This puts them in the Content list, which I think is important.
Attachment #231569 -
Attachment is obsolete: true
Attachment #231892 -
Flags: superreview?(dbaron)
Attachment #231892 -
Flags: review?(dbaron)
Attachment #231569 -
Flags: superreview?(dbaron)
Attachment #231569 -
Flags: review?(dbaron)
Comment on attachment 231892 [details] [diff] [review] fix #2 r+sr=dbaron
Attachment #231892 -
Flags: superreview?(dbaron)
Attachment #231892 -
Flags: superreview+
Attachment #231892 -
Flags: review?(dbaron)
Attachment #231892 -
Flags: review+
Assignee | ||
Comment 25•18 years ago
|
||
Checked in.
Status: ASSIGNED → RESOLVED
Closed: 18 years ago
Resolution: --- → FIXED
Reporter | ||
Comment 26•18 years ago
|
||
I've rebuilt the trunk and verified that roc's fix fixes this bug. thanks roc (dbaron and bz) for fixing this.
Status: RESOLVED → VERIFIED
Reporter | ||
Comment 27•18 years ago
|
||
*** Bug 346307 has been marked as a duplicate of this bug. ***
You need to log in
before you can comment on or make changes to this bug.
Description
•