Open Bug 823059 Opened 12 years ago Updated 2 years ago

display:table clearfix on a rel-pos inline leads to floated kids of that inline being under the anonymous blocks wrapping the block-level tables

Categories

(Core :: Layout: Positioned, defect)

Product:
Core
Component:
Layout: Positioned
Version:
17 Branch
Platform:
x86
Windows XP
Type:
defect

Tracking

()

People

(Reporter: cblackwell, Unassigned)

References

Details

(Keywords: testcase)

Attachments

(1 file)

Minimal test case
1.26 KB, text/html
Details
Attached file Minimal test case — 
User Agent: Mozilla/5.0 (Windows NT 5.1) AppleWebKit/537.22 (KHTML, like Gecko) Chrome/25.0.1364.2 Safari/537.22

Steps to reproduce:

A span with position:relative and the display:table clearfix hack was creating containing another span that was floated left.

See test HTML attachment. This is based on an older version of twitter bootstrap btn-group button groups.


Actual results:

The child element doesn't receive any mouse events like hover or click. This applies to CSS hover styles as well as Javascript event handlers. This bug seems to have been introduced in Firefox 17


Expected results:

Hover styles and javascript event listeners should work as normal
Attachment #693877 - Attachment mime type: text/plain → text/html
The hover doesn't work in Firefox10ESR but works in Opera12 and Safari
Status: UNCONFIRMED → NEW
Component: Untriaged → Style System (CSS)
Ever confirmed: true
Product: Firefox → Core
It works in IE9 too.
Regression window(cached m-c)
Good:
http://hg.mozilla.org/mozilla-central/rev/736619af9701
Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.3a1pre) Gecko/20091101 Minefield/3.7a1pre ID:20091101045105
Bad:
http://hg.mozilla.org/mozilla-central/rev/00924c08d33d
Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.3a1pre) Gecko/20091102 Minefield/3.7a1pre ID:20091102045658
Pushlog:
http://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=736619af9701&tochange=00924c08d33d

In local build:
Last Good : bef4ad958736
First Bad : 0f12f3edad42
Triggered by Bug 501847
Blocks: 501847
Component: Style System (CSS) → Layout: Tables
I don't see how to reconcile comment 3 with the "This bug seems to have been introduced in Firefox 17" in comment 0... or how to reconcile that part of comment 0 with comment 1.

In any case, stripping out the irrelevant parts of the testcase it looks like this:

  <!doctype html>
  <span style="position: relative">
    <span style="float:left; cursor: pointer;">Does hovering me get you a pointer?</span>
    <span style="display: block; clear:both"></span>
  </span>

The display:table is a red herring; the important part is that the display is block-level.

In terms of the actual rendering object tree, there is a rel pos inline containing the float placeholder, then a rel pos block containing the clearing float.  They're positioned, so they get stacking contexts, and in particular the block is positioned over the float.  The _child_ of the block clears the float, but it does so by just having a top margin (since that's what clearance does), which expands the size of its parent anonymous rel pos block but does not change its positioning.

If we posit that the anonymous block should have a stacking context separate from the rel pos inline, this is the behavior the spec calls for, which is why WebKit has the same behavior.  The only question is whether it should have such a stacking context.

(Before bug 501847 we created a single child block for everything from the first block kid to the last one in an {ib} split and stuck everything in it, which is why the ::before thing changed behavior in builds before that fix.)
Component: Layout: Tables → Layout: R & A Pos
Summary: display:table clearfix leads to some elements not receiving events → display:table clearfix on a rel-pos inline leads to floated kids of that inline being under the anonymous blocks wrapping the block-level tables
(In reply to Boris Zbarsky (:bz) from comment #4)
> If we posit that the anonymous block should have a stacking context separate
> from the rel pos inline,

I don't know what you meant by this.

Other browsers make empty boxes transparent to events (in unspecified ways) which probably makes the anonymous rel-pos block transparent to events in this case. We may want to do something like that.
Just for {ib}-split anonymous blocks, I mean; note that nsCSSRendering::PaintOutline already has some special handling for these blocks.
> I don't know what you meant by this.

I think what I meant is that the inline is positioned, so normally it would stack above the anonymous block... except it's _also_ positioned so it goes up in the z-order.  I'm not sure what the "right" behavior here is.  :(
Severity: normal → S3
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: