66147 - relatively positioned elements respond incorrectly to overflowing children

Status: RESOLVED FIXED

(Core :: Layout, defect, P1)

Description

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

When I fixed bug 4519, I changed relatively positioned elements not to cause the
overflow area to expand.  However, the problem of expanding parents occurred
then only when the parent was relatively positioned.  This means there's a
second problem -- how relatively positioned elements respond to overflowing
children.  They shouldn't act differently from static-positioned ones, I don't
think...

Comment 1

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

It could be that my fix to bug 4519 was wrong and this is the right place to fix
that bug.  I need to look at:
 * relatively positioned elements overflowing their views
 * relatively positioned elements in table cells, floats, and auto-sizing
absolutely positioned elements.

It could be that the reflow state needs 2 different overflow areas to handle
this correctly.

Comment 2

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

Reality check.  Moving out to 0.9.1.

Comment 3

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

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

Comment 4

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

This bug is the root of a lot of relative positioning problems, such as bug 76698.

Comment 5

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

I claim that the combinedArea returned by
nsBlockFrameReflowContext::PlaceBlock() for relatively positioned child blocks
should include the relative positioning offset (i.e. the patch in bug 4519
should be undone). We use the combinedArea all over the place with the
expectation that it includes the actual child block's area.

I don't yet see where the combinedArea being used to compute the desired block
height, but I'll keep digging and see if we can't use the in-flow bounds area
instead.

Comment 6

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

Since we currently use the combined area for things like sizing table cells and
floaters (I think), this would cause problems since it would break the
fundamental idea of relative positioning, that the block only affects its
ancestors at its original position.  We shouldn't be using the combined area for
that -- we should have a better concept of a floater containing block that
expands to contain floaters -- and that probably requires a second type of area
(a maxFloaterExtents?).  I'm strongly suspicious of any use of the combined area
for layout (rather than painting).

Comment 7

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

Good, we agree.

Comment 8

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

Attachment: Suggested fix: compute union of line bounds instead of their combinedAreas for NS_BLOCK_WRAP_SIZE

This needs a lot more testing, but it fixes the basic problem and doesn't
regress your testcase in bug 4519.

Comment 9

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

Comment on attachment 75540 [details] [diff] [review]
Suggested fix: compute union of line bounds instead of their combinedAreas for NS_BLOCK_WRAP_SIZE

eh, what was I thinking. never mind

Comment 10

[Brett Donald]

Attachment: Test case and images of expected and actual rendering

The zip file includes screen shots of Mozilla's rendering (incorrect) and
Opera's rendering (correct)

Comment 11

[Malcolm Rowe]

Is there any chance that this bug could get some attention now that 1.0 has 
shipped?  Since I'm developing something which is affected by this bug 
(actually bug 131475), it would useful if anyone could suggest a likely 
timescale for this bug.

Comment 12

[Mikko Virkkilä]

Is this bug related to bug 46983?

Comment 13

[Stefan Seifert]

just to state that this bug causes a lot of real world problems: unfortunately
most of the sites our company produces use Javascript scrollers for design
reasons and these scrollers work with absolute positioned divs inside relative
or absolute positioned divs with overflow: hidden.
This may destroy layouts on Mozilla and cause many other problems like
scrollbars where there is nothing to scroll and make Mozilla's performance
pretty bad.

It would be very nice if someone could take a look at this bug, thanks

Comment 14

[Markus Hübner]

ya - most major portals / sites are using some sort of dhtml scrollers.

Comment 15

[Malcolm Rowe]

Markus, could you provide an example of a 'major portal / site' that is affected
by this bug, please?

Mikko: I think so - it probably depends on this one.

Comment 16

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

Might this be fixed by my patch on bug 180711?  (I haven't tested since there
isn't an easily accessible testcase.)

Comment 17

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

Try this testcase from bug 131475:

http://bugzilla.mozilla.org/attachment.cgi?id=74559&action=view

Comment 18

[Markus Hübner]

Can we get this into 1.3b ?

Comment 19

[Brett Donald]

Taking the hint from dbaron, I have made my test case more easily accessible:

http://www.tagnet.org/castlehill/mozillatest/css2_support_y.html

I've verified that this bug still exists in Mozilla 1.2.1

Comment 20

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

Fixed by the fix to bug 180711 (at least, the problem I originally described). 
I think some of the issues mentioned here are really (comment 19) bug 79315 or
(roc's patches) bug 172896.

Comment 21

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

Er, fixed.

Comment 22

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

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