442542 - Position:absolute elements will not move when window is resized if a sibling contains float elements and a clear:both element

Status: RESOLVED FIXED

(Core :: Layout, defect)

Description

[OwenS]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.1a1pre) Gecko/2008062804 Minefield/3.1a1pre
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.1a1pre) Gecko/2008062804 Minefield/3.1a1pre

Inside an element with position:relative, elements with position:absolute that have 2 or more of the CSS positioning delarations (left, top, right & bottom) will not be repositioned correctly when the browser window is resized, if a sibling of the absolutely positioned element has children that are set to float:left or float:right, and a subsequent child that is set to clear:both.

The bug disappears...
1) if there is an unfloated element before, or in-between, the floats and the clearing element
2) the containing element of the relevant code is floated or absolutely positioned
2) There is only one of the following declarations on the absolutely positioned element:left, top, right or bottom.

Reproducible: Always

Steps to Reproduce:
1. Create a wrapper block-level element such as 'div', set to position:relative
2. Create two child divs, and set the 2nd child element to position:absolute. Let us refer to these two as elem_A and elem_B respectively
3. Add three children to elem_A. Set them to float:left, float:right and clear:both, in that order.
4. Add the declarations 'top:100px;right:50px' to elem_B
5. Add borders/background-colors and inner text if desired, for visibility.
Actual Results:  
The absolutely-positioned element (elem_B) remains in the same place relative to the top-left corner, even when the browser window is resized. Refreshing the page repositions it.

Expected Results:  
The absolutely-positioned element (elem_B) should move with the right hand edge of the browser window as it is resized, constantly remaining 50px from the right hand edge

First observed in the public release of Firefox 3 [   Mozilla/5.0 (Windows; U; Windows NT 5.1; en-GB; rv:1.9) Gecko/2008052906 Firefox/3.0   ] but confirmed in latest build at time of submission [   "Minefield", Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.1a1pre) Gecko/2008062804 Minefield/3.1a1pre   ]

Tested on Mac OSX Leopard & Tiger (intel-based and PowerPC respectively), Windows 2000 & Windows XP, on 'clean', fresh installations with no addons.

Comment 1

[Ria Klaassen (not reading all bugmail)]

Confirmed on Windows XP. Regression range is
http://bonsai.mozilla.org/cvsquery.cgi?module=PhoenixTinderbox&date=explicit&mindate=1196822580&maxdate=1196824139
with bug 406568 and bug 375304 in it.

Comment 2

[j.j.]

Attachment: testcase 1

Comment 3

[j.j.]

Attachment: testcase 2

A bit simpler (saves one div)

Comment 5

[Boris Zbarsky [:bzbarsky]]

This is a regression from bug 406568.  What happens here is that we get into the reflow of the outermost div, discover that we have clearance, and skip reflowing the abs pos kids.  But in nsBlockFrame::ReflowBlockFrame when reflowing that outermost div mayNeedRetry is false, so we actually set the clearance stuff on its parent reflow state.  Then we go ahead and reflow the body a second time, since we discovered the clearance, but that doesn't reflow the outermost div a second time (I assume because it's now clean as far as its flags go and on the second reflow the width of the body doesn't change).

Comment 6

[Boris Zbarsky [:bzbarsky]]

Er, scratch that.  We do reflow the outermost div a second time.  But when we get into reflowing its abs pos kids, we think its width is unchanged (because it did get fully reflowed the previous time), so FrameDependsOnContainer() for the kid returns false (because the offsets are fully specified) and we don't reflow the abs pos frame.

Since we mark lines as dirty in the "will reflow again so bail out" case, should we be marking abs pos frames as dirty too?

Comment 7

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

I think so.

Comment 8

[Boris Zbarsky [:bzbarsky]]

Attachment: Proposed fix

Comment 9

[Boris Zbarsky [:bzbarsky]]

Attachment: Same as diff -w

Comment 10

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

Comment on attachment 342972 [details] [diff] [review]
Same as diff -w

I'd reverse the order of the blocks under if (!aReflowState...) so you can remove the !.

Comment 11

[Boris Zbarsky [:bzbarsky]]

Pushed changeset 7d28d0e7d4d3 with that modification.

Comment 12

[Boris Zbarsky [:bzbarsky]]

Oh, and I'm not sure we want to mess with this on the 1.9.0 branch.  roc, what do you think?

Comment 13

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

I assume that that test is supposed to refer to 442542-subframe.html, not subframe.html ... pushed that as 62315aad3129

Comment 14

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

Isn't this patch quite safe for branch? All we're doing is making more frames dirty, and that should be pretty safe. Right?

Comment 15

[Boris Zbarsky [:bzbarsky]]

Apart from possibly causing performance regressions, yes... but it's not really a good fit for the new branch policy, that I see...

Comment 16

[Boris Zbarsky [:bzbarsky]]

And thanks for fixing the test!  Not sure how that happened.  :(

Comment 17

[Lewis Leighton]

Has this bug crept back in to the 3.0.9 release? I have seen this recently and can repro from the testcases.

Comment 18

[Boris Zbarsky [:bzbarsky]]

Lewis, it was never fixed in Firefox 3.0.anything.  See comment 12 and comment 15 (Firefox 3.0.x is based on Gecko 1.9.0.x; Firefox 3.5 will be based on Gecko 1.9.1, where this bug is fixed).

Comment 19

[Lewis Leighton]

Oh I see, I should have read the comments more closely. I saw resolved/fixed and assumed had been fixed previously. Apologies.