User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.3) Gecko/20040910 Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.3) Gecko/20040910 whole sizes of divs is in em. i create function to resize font size of parent div by client window size. and child div with position absolute, don't redraw his padding and margin in EM with changed parent font size in PT after resizing window. that div redraw his font size, border width, left and top position and more, but not padding and margin. after reload it is ok. Reproducible: Always Steps to Reproduce: 1.resize window to width 1000 px 2.reload 3.resize window to width 800 px 4.see blue box wrap down 5.reload 6.blue box is in line with others (red, green, yellow) Expected Results: resize margins and padding with fotn size and others, like (i'm sad that i must write this} IE

Bug also occurs with Mozilla trunk 2004-11-22-06 on Linux.

So is all that stuff needed? The left margin on the abs pos div, the rel pos container, etc, etc? A minimal testcase would be nice here...

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

I also found another bug...not sure if it's related. I'll make another attachment.

This is the same as the previous testcase except the top and left properties aren't specified, i.e. only position: absolute is specified. Resize to a really small size to the point where the text wraps into multiple lines. Then resize back to a large size so that the text fits on a single line. The text will resize but it won't stop wrapping, i.e. there will still be multiple lines even if there is space for just one line. Apparently the dimensions of the layout box isn't updated yet. However, if you resize it again, the text reverts to a single line, without any of the overlapping element/text issues. So it looks like the first resize will call onresize and change the font-size but won't update the box dimensions. Like I said before, I'm not sure if this is related to this bug.

That looks like a different bug. Please file it separately?

Narrowed it down some more. This actually is completely unrelated to window resizing. Simply changing font-size to a larger value triggers the bug.

Not sure why I obseleted the 1st minimal testcase... Well I filed a separate bug for the 2nd minimal testcase: bug 310451.

Wrapping the div inside another div with position: relative gets rid of the bug. Heh, IE-style hack saves the day.

Dup of bug 199035?

The issue here is that we're not marking the abs. pos. frame dirty when the style change happens. This isn't really the right fix, but it shows what's going on.

dbaron, any suggestions for the correct way to approach this?

Comment on attachment 265664 [details] [diff] [review] Proof-of-concept This patch appears to completely solve this issue; is there some better way to do this?

So is there a general rule for who's responsible for reflowing an out-of-flow frame? I think we reflow floats through their placeholder's position, but reflow absolutely positioned elements through their containing block. Or something like that. I don't see why you'd even need to call FrameNeedsReflow (rather than just pushing onto the stack) when you wouldn't need to also mark intrinsic widths dirty on ancestors. It depends on what the rules for reflowing out-of-flows are (for any given position of containing block, really). (Is there a danger with absolute containing blocks crossing reflow root boundaries? Do we make SVG foreign objects absolute containing blocks?)

WFM (along with bug 310451 and bug 199035, both mentioned above). Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.3a1pre) Gecko/20090823 Minefield/3.7a1pre I don't know whether dbaron's concerns in comment 17 were addressed.