237770 - Mozilla fails to ignore 'float' property even though 'position: absolute' is set

Status: RESOLVED FIXED

(Core :: Layout: Positioned, defect)

Description

[Mikko Rantalainen]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.6b) Gecko/20031208
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.6b) Gecko/20031208

See the attached test case. Mozilla fails to comply with the CSS 2.1 spec and
render the absolutely positioned element in correct location if the 'float'
property is set. This is despite the fact that
http://www.w3.org/TR/2004/CR-CSS21-20040225/visuren.html#dis-pos-flo clearly
says that "[...] if 'position' has the value 'absolute' or 'fixed', the box is
absolutely positioned, the computed value of 'float' is 'none' [...]".

Reproducible: Always
Steps to Reproduce:
1. Open the attached test case in Mozilla or FireFox

Actual Results:  
Notice how the seconds read underscore drops below the second paragraph. If the
'float' property is explicitly set to 'none', the absolutely positioned
underscore ends up where I'm expecting (the first paragraph). However, the
latter paragraph has underscore rendered to left edge of the viewport and one
line below the expected location.


Expected Results:  
Both paragraphs should look the same, including the position of red underscore.

The results are similar with
Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.6) Gecko/20040210 Firefox/0.8

A workaround is to add rule "float: none" in addition to "position: absolute" in
case the 'float' property might have different value otherwise.

The same bug affects "position: fixed" in the same way.

Comment 1

[Mikko Rantalainen]

Attachment: 'float' and 'position: absolute' test case

Comment 2

[Hixie (not reading bugmail)]

But you have left:auto and top:auto, which means the actual position of the
positioned box must be the same as it would have been if 'position' had been
'static', in which case 'float' does affect the results.

Comment 3

[Mikko Rantalainen]

> But you have left:auto and top:auto, which means the actual position of the
> positioned box must be the same as it would have been if 'position' had been
> 'static', in which case 'float' does affect the results.

Is it defined somewhere if computed value of 'float' should be first set to
'none' and the position of the element should be computed after that, or the
other way around?

In addition, the element should be *right* aligned if the 'float' property does
apply first.

Comment 4

[Frédéric Buclin]

Attachment: 2nd test, now specifying left: and top: The layout is fine now

The CSS recommandations mention that left/right and top/bottom need to be
specified. Doing this solves the problem: Mozilla correctly ignores float:
right.

This bug is then INVALID!

(Tested using Mozilla 1.6 final on Linux)

Comment 5

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

Agreed that it's perhaps invalid, but not because anything *has* to be
specified.  Rather, see
http://www.w3.org/TR/2004/CR-CSS21-20040225/visudet.html#static-position and
http://www.w3.org/TR/2004/CR-CSS21-20040225/visudet.html#abs-non-replaced-height

The CSS spec itself isn't clear, but we do weird things that technically can't
be explained within the CSS processing model for compatibility with IE.

Comment 6

[Mikko Rantalainen]

> The CSS recommandations mention that left/right and top/bottom need to be
> specified. Doing this solves the problem: Mozilla correctly ignores float:
> right.

top, right, left and bottom default to 'auto'. I wouldn't call that unspecified
and I cannot see why 'auto' isn't just as good value for those as any absolute
or relative length. The location of absolutely positioned block should be where
the flow puts it, if all the values above are 'auto'. Either the "position:
absolute" modifies the "float: right" to "float: none" before laying out the
boxes and the 'float' property gets ignored, *or* the element is floated to
*right* and then *that* location is used because all of top, right, left and
bottom are auto.

Regardless of which way you think is the correct interpretation of the spec, the
floated/positioned element shouldn't be put on the left edge of the containing
box (speaking about test case 1 with "float: right"). It seems to me that MSIE
already works to my interpretation of the spec (at least with a this simple test
case).

Comment 7

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

Oops, I didn't mean to mark invalid.

Comment 8

[Boris Zbarsky [:bzbarsky]]

So the basic problem is that the "float" forces the display to "block", even if
"position" is set to absolute...  Mikko, what exactly is IE's behavior on this
testcase?  Opera's behavior is to not apply the display fixup in this case,
looks like (Opera 7.23 Linux).  Konqueror (only 3.03, unfortunately) renders
both underscores like Mozilla does the second one, which is clearly wrong (it's
not keeping track of the original display type at all).

Comment 9

[Mikko Rantalainen]

> what exactly is IE's behavior on this testcase?

MSIE 6.0.2600.0000 (with "Update Versions: Q316059, q319182, Q323759, Q328970,
Q324929, Q330994") on Windows 2000 renders the first test case (after saving it
to harddrive to workaround the missing support for the application/xhtml+xml
content type) for both paragraphs like the "float: none" were specified. I guess
the MSIE applies the "position: absolute" -> "float: none" logic before
computing the flow position for the element. MSIE doesn't support "position:
fixed" which should work in a similar way.

Opera 6.0/win32 renders both paragraphs of the first test case like Mozilla does
the second (which is incorrect behavior). Opera 7.0/win32 build 2349 has
interesting behavior: it renders both underscores in correct horizontal position
but one line below the correct position (the same "top", relative to paragraph,
as Mozilla's second paragraph's rendering for both underscores and the same
"left" for both underscores as the Mozilla has for the first underscore).

The second test case seems to work with all the browsers, so the problem is with
the value 'auto' for 'top', 'left', 'right' and 'bottom'. According to the spec
the element is supposed to use "static position" with shrink-to-fit in that
case. The question is whether the 'float' property is set to 'none' before or
after computing the "static position". MSIE seems to set it to 'none' first.

Comment 10

[Frédéric Buclin]

I think David Baron found something interesting in chap. 10.3.7 and 10.6.4:

If all three of 'left', 'width', and 'right' are 'auto' [which is the case in
the first test case]: First set any 'auto' values for 'margin-left' and
'margin-right' to 0. Then, if 'direction' is 'ltr' set 'left' to the static
position and apply rule number three below.

And rule #3 is:

3. 'width' and 'right' are 'auto' and 'left' is not 'auto', then the width is
shrink-to-fit . Then solve for 'right'.


The same description applies for the top/height/bottom attributes. In other
words: Mikko would be right! ;-)

-------  BUT --------

I discovered something more annoying:

Replace #y {float: right} in the first test case by #y {float: none}. What do
you see??? Something very bad, isn't it? No matter what float is, Mozilla is
working wrong with it!

I will put a 3rd test case with the new valur for float.

Comment 11

[Frédéric Buclin]

Attachment: 3rd test case with #y {float: none}

Mozilla behaves incorrectly when float is declared twice!!

Comment 12

[Frédéric Buclin]

There is definitively some problem here:

If you write #y {float: none} as in case test #3, the test fails.
But if you write either #x {float: none} or #x, #y {float: none} instead of the
previous command, everything is running fine!

Has someone an explanation?

Comment 13

[Boris Zbarsky [:bzbarsky]]

That's a totally separate bug.  I've filed bug 237891 on it.

Comment 14

[Frédéric Buclin]

Does this bug depends on bug #237891 ?

Comment 15

[Boris Zbarsky [:bzbarsky]]

Attachment: 4th testcase

Although, amusingly enough, it seems that fixing bug 237891 may "fix" this bug.
 I'll attach an updated testcase for this bug that won't get fixed by fixing
that one, hopefully.

Comment 16

[Mats Palmgren (inactive)]

Boris, this is a duplicate of bug 168971?

Comment 17

[Boris Zbarsky [:bzbarsky]]

Very possible.... Marking dependent for now, but they could well be dups.

Comment 18

[Mikko Rantalainen]

1st and 4th test still don't work with Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9a1) Gecko/20060404 Firefox/1.6a1 ID:2006040404. Konqueror 3.5.0 and Opera 9.0 both render test cases correctly.

Comment 19

[Eli Friedman]

Attachment: Patch

The issue here is that the mOriginalDisplay wasn't getting set to the correct value when both position and float were set.

Comment 20

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

Comment on attachment 265645 [details] [diff] [review]
Patch

What happened to the code for ::first-letter?

(bzbarsky should probably review as well.)

Comment 21

[Eli Friedman]

(In reply to comment #20)
> (From update of attachment 265645 [details] [diff] [review])
> What happened to the code for ::first-letter?
> 
> (bzbarsky should probably review as well.)

From reading bug 103189, I was kind of under the impression it was fixed.  Am I wrong?

Comment 22

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

No, it's not fixed correctly.

Comment 23

[Eli Friedman]

Attachment: Patch v2

Okay, then; this version should work.

Comment 24

[Boris Zbarsky [:bzbarsky]]

Comment on attachment 265744 [details] [diff] [review]
Patch v2

Looks good.

Comment 25

[Eli Friedman]

Checked in.