281267 - {inc} Clear is sometimes not respected.

Status: RESOLVED FIXED

(Core :: Layout: Floats, defect)

Description

[andershol]

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

It seems that the css-attribute "clear" is not respected for floats that is only
suspended by a absolutely positioned element.

Sorry for the bad summery, but I can't really figure out what is going on.

Reproducible: Always

Steps to Reproduce:
1. View the test case and observe that the red div (that have clear:both) is
poistioned after the green floated div.
2a. Use the tab key to make the linked "a" active or
2b. Use the mouse to click the link again giving to link focus (the cursor can
be move from the link after clicking) or
2c. Use the mouse to hover the link (notice that the link isn't active using
this method).
3. Observe that the red div is move up so the green and red div overlap.

4a. Use the tab key twice (so "b" loses focus) or
4b. Click the linked "b" and the click outside the link (so "b" loses focus) or
4c. (if 2c was used) Hover the linked "b"
5. Observe that the the red div moves to its initial position.

Actual Results:  
The position of the elements change position inconsistenly with the style sheet
(i.e. position change on certain focus changes, but where are not :active rules,
also even though there are a :hover rule, the position is not changed back on
mouseout).

Expected Results:  
I don't know what the spec say is the right position, but I don't think the
position should change (at least not when using 2a and 2b since there are not
:active rules). It would be somewhat easier to comprehed if the green div
changed size.

Comment 1

[andershol]

Attachment: Test-case

Comment 2

[Mats Palmgren (inactive)]

Regression interval: 2004-11-25-06 -- 2004-11-26-06 (bug 209694?)

Comment 3

[Robert O'Callahan (:roc) (email my personal email if necessary)]

Attachment: fix

We must not take the fast path for incrementally reflowing absolute frames if
we have floats and we do not have our own space manager; we need to ensure that
those floats are recovered and their areas added to the parent's space manager.


Also we need to reflow lines if we have any descendants with 'clear', because
they might need repositioning.

Comment 4

[Robert O'Callahan (:roc) (email my personal email if necessary)]

*** Bug 278861 has been marked as a duplicate of this bug. ***

Comment 5

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

Comment on attachment 173565 [details] [diff] [review]
fix

What if mFloats is empty but a block child's mFloats is not?

Comment 6

[Robert O'Callahan (:roc) (email my personal email if necessary)]

You're right. I'll think it over. I suspect we just have to disable the
incremental-absolute-reflow path for blocks which don't have their own space
manager, since locating any blocks under us will require traversal of the line list.

Comment 7

[Robert O'Callahan (:roc) (email my personal email if necessary)]

Attachment: fix #2

OK, take two. Now I'm not testing whether we have floats or not --- just
assuming that there are floats in this block or its descendants. This means
we're disabling the fast incremental absolute reflow optimization for all
blocks which are absolute containers but not space managers. As far as I know,
that's only relatively positioned blocks. I hope that doesn't hurt us too much.

Comment 8

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

Comment on attachment 173578 [details] [diff] [review]
fix #2

oh well.  Maybe we should make the state managers more permanent so we don't
need to do this.

Comment 9

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

(In fact, I may end up doing that on the reflow branch.)

Comment 10

[Robert O'Callahan (:roc) (email my personal email if necessary)]

Patch regression-tested (no changes) and checked in.

Comment 11

[andershol]

Using build 2005031304, both the test-case and the site from which it was
reduced seems to work correctly. Thank you.

Comment 12

[jhp (no longer active)]

Caused regression -> bug 299742.

Comment 13

[Boris Zbarsky [:bzbarsky]]

We do seem to have some reports of performance issues this caused, but not very many (the two bugs blocking this one so far).

Comment 14

[Worcester12345]

(In reply to comment #13)
> We do seem to have some reports of performance issues this caused, but not very
> many (the two bugs blocking this one so far).
> 

This bug was marked fixed in March. How can it still be "blocked"?

Comment 15

[Boris Zbarsky [:bzbarsky]]

It's blocked by the regressions it caused.