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)

Product:
Core
Component:
XUL
Platform:
x86
Windows XP
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

()

Status:
VERIFIED FIXED

People

(Reporter: moco, Assigned: roc)

References

Details

(Keywords: testcase)

Attachments

(5 files, 1 obsolete file)

test case
749 bytes, application/vnd.mozilla.xul+xml
Details
screen shot
16.25 KB, image/png
Details
screen shot of the test case on the mac trunk
21.38 KB, image/tiff
Details
screen shot of the test case on the mac branch
51.80 KB, image/tiff
Details
fix #2
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)
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.
Likely view related. roc did a lot of work in this area for 1.9 so he may know what is going on.


Not sure what it is but I think there is some relationship here with bug 317125

bz and mconnor just discovered a workaround!

set the opacity of the button to .999 and it works as expected (trunk and branch)

Is this even an issue on trunk?  This looks like a dup of one of the deps of bug 317375....
> 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.
Keywords: testcase
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?
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.
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
I've spun out the "after a certain point, the .999 opacity trick stops working" to bug #346307.
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.
> 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>
(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).
Attached patch fix (obsolete) — — Splinter Review 
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.
Attached patch fix #2 — — Splinter Review 
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+
Checked in.
Status: ASSIGNED → RESOLVED
Closed: 18 years ago
Resolution: --- → FIXED
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
*** Bug 346307 has been marked as a duplicate of this bug. ***
Blocks: 360473
Blocks: 360474
No longer blocks: 360473
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: