regression: display: -moz-box; style rule in a XHTML document makes XUL elements not clickable

RESOLVED FIXED in mozilla1.9alpha1

Status

()

RESOLVED FIXED
13 years ago
7 months ago

People

(Reporter: mano, Assigned: roc)

Tracking

({regression, testcase})

Trunk
mozilla1.9alpha1
regression, testcase
Points:
---
Dependency tree / graph

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(2 attachments, 1 obsolete attachment)

Found this while working on the trunk patch for bug 346009.

If a XUL element in a XHTML document is under a -moz-box element (i.e. <xul:hbox> or a <xul:vbox>), it doesn't respond (at all, meaning that there's also no "active" state for themes) to click/mousedown. If I however, put a div or a span in betwenn, the element is clickable again. Note you can tab to the element and activate it using the keyboard. This is a trunk-only issue AFAICT.

For bug 346009, I'm checking in a workaround for the subscribe button, but i couldn't work around it for the checkbox, which relies on being inside a -moz-box.
Asking for blocking1.9 since this breaks feed subscription UI.
Flags: blocking1.9?
Target Milestone: --- → mozilla1.9alpha
Keywords: testcase
This regressed between 2006-01-21 and 2006-01-26, probably a regression from bug 317375.
Blocks: 317375
Typical display list here:

Event handling --- (952,420):
Background 0x892e9bc(HTMLScroll(html)(-1)) (0,0,14812,8624) uniform
Clip (nil)() (0,0,14812,8624)
    CanvasBackground 0x892e878(Canvas(html)(-1)) (0,0,14812,8624) uniform
Clip (nil)() (0,0,14812,8624)
    Background 0x8930688(Area(html)(-1)) (0,0,14812,770) uniform
    Background 0x8930940(Block(body)(3)) (112,112,14588,546) uniform
    Background 0x8930c38(ButtonBoxFrame(button)(0)) (182,126,1411,504)
    Border 0x8930c38(ButtonBoxFrame(button)(0)) (182,126,1411,504)
    Background 0x89309e8(Box(hbox)(1)) (112,112,1551,546) uniform

How did the background of the Box end up above the background of its kid?  That would seem to be the problem to me...  Is the relevant code the following in nsBoxFrame::BuildDisplayListForChildren:

  // Put each child's background onto the BlockBorderBackgrounds list
  // to emulate the existing two-layer XUL painting scheme.
  nsDisplayListSet set(aLists, aLists.BlockBorderBackgrounds());

combined with the fact that the background of the box itself is NOT in BlockBorderBackgrounds (since its parent is not a box and it's not a block as far as nsBlockFrame is concerned)?
Component: Layout → Layout: View Rendering
Target Milestone: mozilla1.9alpha → ---
Assignee: nobody → roc
QA Contact: layout → ian
Indeed.

I suppose that in the context of
http://www.w3.org/TR/CSS21/zindex.html
we should probably treat backgrounds of XUL boxes inside blocks in step 4 as block-level descendants under "block, list-item, or other block equivalent".
Ah, but in this case the hbox is inline-level, for better or worse. So instead we should treat it like an inline-block.
In fact we already handle -moz-inline-box. Here the situation is that the hbox is display:-moz-box and yet in a line of inlines :-(.
Posted patch fix (obsolete) — Splinter Review
Stem the tide of these fixes by just forcing all non-inline elements in inline context into a pseudo-stacking-context.
Attachment #235534 - Flags: superreview?(dbaron)
Attachment #235534 - Flags: review?(dbaron)
Comment on attachment 235534 [details] [diff] [review]
fix

Unfortunately 'display' isn't used for constructing things like our HTML form controls, so this will regress what you have in the listControlFrame check.

One option is to do a frame type check -- against inlineFrame, positionedInlineFrame, lineFrame, bulletFrame, brFrame, and textFrame.  And maybe directionalFrame.  And maybe null.  Hopefully pageBreakFrame and placeholderFrame and spacerFrame don't matter.

Another option might be to check !inline ||  (GetStateBits() & NS_FRAME_REPLACED_ELEMENT).
Attachment #235534 - Flags: superreview?(dbaron)
Attachment #235534 - Flags: superreview-
Attachment #235534 - Flags: review?(dbaron)
Attachment #235534 - Flags: review-
The latter sounds better to me.

Another option would be to just unconditionally put inline children in a pseudo-stack. I think that would be correct.

Updated

13 years ago
OS: Mac OS X 10.3 → All
Hardware: Macintosh → All
Posted patch fixSplinter Review
This does your latter suggestion. I have to also check IsContainingBlock to catch fieldsets, which aren't replaced elements.
Attachment #235534 - Attachment is obsolete: true
Attachment #239116 - Flags: superreview?(dbaron)
Attachment #239116 - Flags: review?(dbaron)
I checked that this doesn't regress bug 331590 or bug 336121.
checked in.
Status: NEW → RESOLVED
Last Resolved: 13 years ago
Resolution: --- → FIXED
Flags: blocking1.9?
Target Milestone: --- → mozilla1.9alpha
Component: Layout: View Rendering → Layout: Web Painting
Product: Core → Core
You need to log in before you can comment on or make changes to this bug.