145141 - DIVs with relative positioning and hidden overflow incorrectly affects the page layout

Status: RESOLVED DUPLICATE of bug 172896

(Core :: Layout, defect, P3)

Description

[Roger C. Soares]

When moving an element inside a DIV with relative position and hidden overflow,
it causes the inner element to be clipped by the outter DIV, but the inner
element affects the DOM around the outter DIV.

Comment 1

[Roger C. Soares]

Attachment: DIV inside DIV affecting outside table

table: yellow
relative DIV: blue
absolute DIV inside relative DIV: green

the green DIV is hidden by the blue DIV, but it affects the table as if the
overflow was visible. Moving the green DIV will reflow the table.

Expected, the green DIV shouldn't affect elements outside the blue DIV clipping
area.

Comment 2

[Laura Krietemeyer]

Changing QA Contact

Comment 3

[/\/\arcio Galli]

Peter, 

have you seen this cases? The clipped area of a DIV is pushing content to the
bottom or to the right. 

Comment 4

[Chris Waterson]

I doubt the clipping has anything to do with this.

Comment 5

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

This is a general bug with tables and relative positioning (probably a
duplicate), which should never affect the position of the table.  The problem is
that the tables are using mOverflowArea for layout, when it should really only
be used for painting/event targetting optimization.  Instead, table cells should
be using some notion of a block formatting context that they contain (i.e.,
containing blocks and floats, similar to what floaters do for their own content,
where they use the space manager's YMost() if it's lower than the bottom of the
block inside.).

Comment 6

[Kevin McCluskey (gone)]

-> Karnaze

Comment 7

[/\/\arcio Galli]

Attachment: minimum testcase

Comment 8

[/\/\arcio Galli]

Added doron to the cc and a minimun testcase to this bug since this fix is
needed  for AOL Brasil, specifically in the Mapafacil service in Brazil
(http://www.mapafacil.com.br). 

Comment 9

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

Fixing either bug 46893 *or* bug 46257 should fix the main issue in this bug
(although there's an additional bug with the first testcase changing
horizontally the first two times the user presses one of the buttons).  Setting
dependency on both, even though that seems to suggest logical and rather than
logical or.

Comment 10

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

I meant bug 46983, not bug 46893.

Comment 11

[Angus]

Attachment: Nested divs overflow/visibility example.

I'm using the latest Phoenix nightly (Gecko/20021013), and have found a script
of mine that worked fine in Mozilla 1.1 Final but not this pre-1.2b engine.

The URL is http://www.twinhelix.com/dhtml/scripts/hvscroll.html for the
original script, but it's pretty complicated. I've attached a minimal example
to this bug.

Summary: I've nested divs in a table cell, the outer one is relatively
positioned and has overflow: hidden set on it, and the inner one is absolutely
positioned (normally moves inside the outer, this is fine when I test it). All
is well until you execute style.visibility = 'visible'; on the inner one, which
causes the table cell containing the divs to shrink.

If it's unrelated I'll file a new BugZilla report (sorry, this is my first bug,
still finding the ropes :), but it seems to be the same kind of problem. If
it's possible to fix this by 1.2 final it would be great as otherwise I'll have
to code in another layer of workarounds in my script.

Comment 12

[Susie Wyshak]

If you know of websites affected by this please add them to this bug. 

Comment 13

[Krister Nielsen]

http://www.norwegianbastard.net/

exhibits the same bug mentioned by Angus Turnbull. The problem here is simply
that the body has overflow set to hidden and all content is absolutely
positioned. The spec *clearly* states that if you set position:absolute for an
element in a  non-positioned containing box (that would be the body in this
case), the containing block is no longer the non-positioned box. Thus, the
absolutely positioned divs should not be considered overflow.

The bug is confirmed in the latest nightly build (2002110208).

As I said, the spec is quite clear:

C.f. http://www.w3.org/TR/CSS21/visudet.html#containing-block-details

Quote: "If we position "div1":

#div1 { position: absolute; left: 50px; top: 50px }

its containing block is no longer "body"; it becomes the initial containing
block (since there are no other positioned ancestor boxes). "

Sincerely,

Krister

Comment 14

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

comment 11 and comment 13 seem unrelated both to this bug report and to each
other, and should be filed as separate bugs.

Comment 15

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

Regarding comment #13: you're absolutely right that the BODY is not the
containing block for the positioned element. However, I believe the spec wants
'overflow:hidden' to apply to *all* children of BODY, not just the children for
which BODY is the containing block, although I admit there is a slight ambiguity
in the spec about this.

(dbaron, did you get any feedback from the WG on this?)

Comment 16

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

Nope.  I'll ping the WG again.

Comment 17

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

Comment 13 is probably appropriate for bug 170011.

Comment 18

[Krister Nielsen]

Yes, the latter comments seem to be more appropriately applicable to bug 170011
(my initial search did not turn up this bug report, since it is quite vague in
its formulation).

Robert: "However, I believe the spec wants 'overflow:hidden' to apply to *all*
children of BODY, not just the children for which BODY is the containing block,
although I admit there is a slight ambiguity in the spec about this."

This would seem, however, to be irrelevant for this bug. The spec (the part I
quoted) specifically state that the absolutely positioned div is to be
considered contained by, not BODY, but the "initial containing block" (which
wouldn't be a child of BODY).

Additionally, even if the 'overflow: hidden' applies to the absolutely
positioned div itself, the div should still be shown: its contents aren't
overflowing its dimensions (since width and height are defaul -> auto, which
implies - at minimum (depending on spec version and interpretation) -
"shrink-wrapping" of the content).

Sincerely,

Krister

Comment 19

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

Please discuss things related to comment 13 on bug 170011, not here.

Comment 20

[Chris Nalls]

Marking topembed+ as per topembed triage

Comment 21

[karnaze (gone)]

Attachment: patch to fix the bug

The patch in bug 172896 may fix this also (I'm not sure) but it still has some
problems, and this patch also appears to fix the problem mentioned in comment
#9.

Comment 22

[karnaze (gone)]

Attachment: patch to fix the bug

The patch in bug 172896 may fix this also (I'm not sure) but it still has some
problems, and this patch also appears to fix the problem mentioned in comment
#9.

Comment 23

[karnaze (gone)]

Comment on attachment 105886 [details] [diff] [review]
patch to fix the bug

bugzilla was so slow, I guess I hit submit twice.

Comment 24

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

I have patches in another bug which take OVERFLOW_HIDDEN into account for the
overflow area, and clean up some other issues besides. The necessary and
sufficient solution to this problem here is to not use the overflow area for layout.

Comment 25

[karnaze (gone)]

roc, since this bug is topembed+ (and requests ETA in the status field), could
you please dup it against your bug and mark yours topembed+. If you don't use
the overflow area at all, then won't tables break?

Comment 26

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

I think this is really dbaron's bug since he's the one working on removing the
dependence on the overflow area. I'll defer to him.

Comment 27

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

bug 172896 is about not using the overflow area for layout, and I found only one
minor problem in the regression tests (the max-element-size and max-width
computation already includes overflowing blocks, so all that needs doing is
accounting for floats).  roc's patch is I think bug 170330 (which fixes what
attachment 105887 [details] [diff] [review] does, but in a more general way), which I suspect will fix bug
46257.  See the dependency tree.  As I said in comment 9 / comment 10, either
one of those will fix this bug.

I don't understand what the first change in attachment 105887 [details] [diff] [review] is, though.

Comment 28

[karnaze (gone)]

The 1st part of attachment 105887 [details] [diff] [review] was necessary (probably because of the other
changes), so that the mes would get calculated while exercising attachment
84011 [details]. Without it, mes was deadbeef.

Comment 29

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

Let's not do this patch. Let's focus on dbaron's fix.

Comment 30

[karnaze (gone)]

*** This bug has been marked as a duplicate of 172896 ***

Comment 31

[karnaze (gone)]

Comment on attachment 105887 [details] [diff] [review]
patch to fix the bug

clearing request for reviews.