105520 - table after left float is next to float even when it doesn't fit

Status: RESOLVED WORKSFORME

(Core :: Layout: Block and Inline, defect, P1)

Description

[K Hopper]

This page apparently loads normally - but ALL of the 'body' text is well to the 
right of the browser window (ie has been displayed to the right of the table).  
The main body of the page is a single row two cell table - the second cell 
contains all of the text apart from page header and footer.  The bug is also 
apparent using xml source - not surprising due to its nature!

The pages (the above is not the only one!) were created/tested using the w3c 
editor/browser Amaya (Windows and linux!) and also render correctly when tested 
in Oregan Developments Oregano 1.10 browser (used on an Acorn RISC PC).  Other 
offending pages are up to twice the size of the example referred to!

This seems to be a bug of long standing - but only just come to light - it 
certainly occurs in all version of Mozilla back to 0.9 (Netscape 4.1+) that I 
have been able to test.  I understand the fault is also present in the Opera 
browser - but I have no first hand knowledge of this.

Comment 1

[K Hopper]

Attachment: Table cell overflow example source

Comment 2

[Boris Zbarsky [:bzbarsky]]

The page has:

<table align="left" width="95%">
<!-- Header in here -->
</table>

<table border="0">
<!-- body in here -->
</table>

This problem does _not_ occur if the floater is a div.  Ccing waterson.

Comment 3

[mike west]

Attachment: simplified test case

Comment 4

[mike west]

this behavior seems correct to me.  the top table is defined with "align='left'
width='95%'".  this means that the next element will flow directly to it's
right, in the 5% of the browser window that remains.  the second table tries as
hard as it can to wrap itself within that 5%, but can't due to the size of some
of it's contained elements.  i'm uploading a simplified test case, turning on
borders so that you can see the tables more clearly, and removing most of the
extra data. 

opera 5.12, IE 6 and NS 4.78 all render it in more or less the same way (table
two beginning at 95% and wrapping as much as it can.)

do you expect it to render differently?

Comment 5

[karnaze (gone)]

flaoater. -->attinasi

Comment 6

[Christopher Hoess (gone)]

Attachment: Comparative floater testcase

Comment 7

[Marc Attinasi]

Moving Mozilla 1.01 bugs to 'future' milestone with priority P1

I will be pulling bugs from 'future' milestones when scheduling later work.

Comment 8

[Bernd]

attinasi will probably not work on those bugs :-(

Comment 9

[Boris Zbarsky [:bzbarsky]]

Actually, if the floater is a div and you don't screw up setting its width you
do get identical rendering.

mike west is right -- this is invalid.

Comment 10

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

But if it can't fit, maybe it should try to be below the float instead of next
to it?

Comment 11

[Boris Zbarsky [:bzbarsky]]

True... And that works with text and images.  Is the problem that we get an
incorrect MES somewhere?

Comment 12

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

We actually probably have an explicit quirk to force it not to wrap, or
something ugly like that.

Comment 13

[Bernd]

The code to be ashamed off is at
http://lxr.mozilla.org/seamonkey/source/content/html/content/src/nsHTMLTableCellElement.cpp#490

Comment 14

[Boris Zbarsky [:bzbarsky]]

Er... Except none of the tables here have nowrap attributes set?

Comment 15

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

The quirk I was thinking of was:
http://bonsai.mozilla.org/cvsblame.cgi?file=mozilla/layout/html/base/src/nsBlockReflowState.cpp&rev=3.475&cvsroot=/cvsroot&mark=884-885,889-938#882

Removing this quirk would make it much easier to fix a bunch of other float bugs
since it would allow us to separate the "flow" and "place" parts of
"FlowAndPlaceFloater".

Comment 16

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

Although it's only the quirk-within-a-quirk at
http://bonsai.mozilla.org/cvsblame.cgi?file=mozilla/layout/html/base/src/nsBlockReflowState.cpp&rev=3.475&cvsroot=/cvsroot&mark=892-924#882
that causes this bug.

Comment 17

[Boris Zbarsky [:bzbarsky]]

But in this case the second table is _not_ floated, so that code shouldn't
apply, should it?  Agreed that that quirk is ugly.  :(

Comment 18

[Boris Zbarsky [:bzbarsky]]

Attachment: Same testcase as "simplified test case", but standards mode

This shows the bug too.  So this ain't a quirk.

Comment 19

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

Ah, right.  So it's basically the same as: 
http://dbaron.org/css/test/2003/float-and-overflow/outside-scroll

Comment 20

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

What's going on starts in nsBlockReflowState::ComputeBlockAvailSpace, but the
real problem is that there's no loop in nsBlockFrame::ReflowBlockFrame or
nsBlockReflowContext::ReflowBlock like there is in
nsBlockReflowState::FlowAndPlaceFloat.

Comment 21

[Boris Zbarsky [:bzbarsky]]

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

Comment 22

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

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

Comment 23

[Boris Zbarsky [:bzbarsky]]

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

Comment 24

[Mats Palmgren (inactive)]

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

Comment 25

[Erik Fabert]

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

Comment 26

[Boris Zbarsky [:bzbarsky]]

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

Comment 27

[Andrew Schultz]

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

Comment 28

[Steve England [:stevee]]

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

Comment 29

[Eli Friedman]

I think part of the issue here is that the behavior isn't really specified.  I
don't think there is any explicit allowance in CSS 2.1 for wrapping tables,
images, boxes with overflow set, etc. when they are set to display: block (or
display: table; I don't thinnk it matters).  The closest thing I can find is
http://www.w3.org/TR/CSS21/visuren.html#q15, which does not seem to allow
vertically repositioning blocks.

The proposed solution seems to be to repeatedly try to place the table further
and further down until it fits.  This is much closer to wrapping in the inline
box model than to floats, which either fit next to the last float or are pushed
below it.  I guess it would be treated like a cleared element for margin
collapsing.  However, all of this is just an idea for dealing with the
unspecified behavior of floats next to these blocks.

In Opera 8 and IE, the block is placed next to the first float it fits next to
horizontially, or below all floats if it doesn't fit next to any float.  This
behavior probably would be an improvement, but it does cause overlaps if a wide
float follows a narrow one.  I'll attach a testcase that shows what I mean.

Comment 30

[Eli Friedman]

Attachment: More comprehensive test

Comment 31

[Michal 'hramrach' Suchanek]

I guess the last testcase shows a really bad behavior where part one of the blue
rectangles overlaps one of the purple rectangles.
This means removing content in case both of the rectangles actually contained
something.
Since the spec does not say anything clearly at least losing parts of content
should be avoided.

Comment 32

[fyodor]

The CSS2.1 spec is *completely* clear on this issue. I'm surprised this bug has
gone unfixed for almost 4 years:

http://www.w3.org/TR/CSS21/visuren.html#floats

"The margin box of a table or an element in the normal flow that establishes a
new block formatting context (such as an element with 'overflow' other than
'visible') must not overlap any floats in the same block formatting context as
the element itself. If necessary, implementations should clear the said element
by placing it below any preceding floats, but may place it adjacent to such
floats if there is sufficient space."

Comment 33

[Boris Zbarsky [:bzbarsky]]

> I'm surprised this bug has gone unfixed for almost 4 years:

That spec hasn't been around for 4 years.  If you think this is easy to fix on
short notice, feel free to fix it.

Comment 34

[fyodor]

> That spec hasn't been around for 4 years.

No, it's "only" been around (in final form) for well 1.25 years - and although I
believe the original CSS2 spec (7 years old) strongly alludes to the same
behavior as explicitly defined in the 2.1 spec, that is clearly irrelevant at
this point.

What I take issue with is the sentiment that there is ambiguity in the 2.1 spec
on this point. The spec states, verbatim, that "the margin box of a table [...]
must not overlap any floats in the same block [...]".

Any remaining ambiguity must be tied to the case of multiple floats (below each
other) of different widths in the same block formatting context and whether a
table (or other element) should be shifted below all subsequent floats if it
fails to fit next to a given float - or whether the table should be shifted
below all floats. The use of the word "clear" may be what is causing the
residual confusion: "If necessary, implementations should clear the said
element". However, applying the "clear" property would have repercussions
outside the formatting context in question, which neither seems logical nor fits
well with the remaining language of the specification on this point.

The only remaining solution is to move the table (or other) below the float in
question when not enough space is available for the two to fit next to each
other. In cases where a subsequent float is encountered, and if space is again
an issue, the table must be moved further down.

The comments of Eli, in particular, are particularly troubling, in that he makes
several egregious statements. One example would be that the spec "does not seem
to allow vertically repositioning blocks" in this case. That is most evidently
incorrect, cf the quote from the spec in my first comment. He furthermore
contends that "In Opera 8 and IE, the block is placed next to the first float it
fits next to horizontially, or below all floats if it doesn't fit next to any
float", while his own following statements and his test case clearly show that
the block is indeed not placed below ALL floats, but only shifted down a single
float - still leaving an overlap (given circumstances) and thus clearly in
violation of the spec.

Only 3 rendering options that I can see have any merit whatsoever (i.e.
fullfills the letter of the spec):

1. Shifting the table down one float at a time until it fits.
2. Shifting the table below ALL floats in the given block.
3. Clearing the table (by applying the clear property).

There is nothing whatsoever that lends any additional weight to the second
option and the third option, as noted earlier, strives against the logic and
"spirit" of the remaining specification on this point. That leaves the first
option as the clearly preferable option.

Comment 35

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

The original CSS2 spec really doesn't allude to it at all.

Please stop posting verbose comments in the bug; we know it's a bug, adding
comments will only make the bug more confusing and less likely to be fixed.

(FWIW, there may need to be some differences in quirks mode.)

Comment 36

[Martijn Wargers (dead)]

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

Comment 37

[Boris Zbarsky [:bzbarsky]]

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

Comment 38

[Mats Palmgren (inactive)]

Attachment: Testcase #6

Comment 39

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

Mats, I think your retitling is too broad.  This behavior applies only to replaced elements, tables, and things that establish new block formatting contexts.  We might need separate bugs for some of these, although I may have to fix some for bug 349255.

Comment 40

[Mats Palmgren (inactive)]

Attachment: Like so?

This makes us compatible with IE7b2 and Opera 9 for all the cases in
Testcase #6, except for a minor difference on the <fieldset>s.

For the fieldsets:
IE7: text overflows, the block is moved down only when size=0
Op9: text overflows, the block is moved down only when size="some
     small width (internal padding?)"
Gecko with patch: the block is moved down before the text starts
                  to overflow.

Comment 41

[Mats Palmgren (inactive)]

Comment on attachment 240283 [details] [diff] [review]
Like so?

I should have said also that the patch fixes all the duplicates
and the listed dependent bugs.

Comment 42

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

You're clearing all floats. Do you really want to do that? Couldn't the block fit next to a narrow float further down?

Comment 43

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

For tables at least, and probably also for some replaced blocks it's much easier to fix this properly (and without multiple "retry" passes) after the reflow branch lands.  I'd prefer if you either (a) wait or (b) work on it on the reflow branch (although non-block-like replaced elements still need some work in nsHTMLReflowState before the fix will work, but that work needs to happen for other reasons too).

Comment 44

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

Comment on attachment 240283 [details] [diff] [review]
Like so?

we need a new patch per David's comment

Comment 46

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

This is fixed, probably via bug 134706.

Comment 47

[Daniel.S]

Attachment: Is this correct?

In this tesctase, the table is right to the div, even though its 100% wide.

I couldn't figure wether this is correct or not, sorry. Could you please tell me?

Comment 48

[Andres Rios]

(In reply to comment #47)
> Created an attachment (id=354076) [details]
> Is this correct?
> In this tesctase, the table is right to the div, even though its 100% wide.
> I couldn't figure wether this is correct or not, sorry. Could you please tell
> me?

This looks fine to me, you said code specified 100%, so what happens, the blue square appears in the browser window, so to have a 100% width, the next piece needs to go underneath.

Looks good to me.

Comment 49

[Andres Rios]

(In reply to comment #47)
> Created an attachment (id=354076) [details]
> Is this correct?
> In this tesctase, the table is right to the div, even though its 100% wide.
> I couldn't figure wether this is correct or not, sorry. Could you please tell
> me?

This looks fine to me, you said code specified 100%, so what happens, the blue square appears in the browser window, so to have a 100% width, the next piece needs to go underneath.

Looks good to me.

Comment 50

[Daniel.S]

It's the difference to Opera and IE that worries me. Both put the table below the float instead of next to it. I usually "trust" Opera in such cases.

Comment 51

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

That testcase is showing a variant of bug 25888, except where we're checking something above the top pixel (perhaps due to margin collapsing).

It might be worth having a separate bug on file for the block-wrapping-around-floats variants of bug 25888, though.