Last Comment Bug 105520 - table after left float is next to float even when it doesn't fit
: table after left float is next to float even when it doesn't fit
Status: RESOLVED WORKSFORME
[reflow-refactor]
: testcase
Product: Core
Classification: Components
Component: Layout: Block and Inline (show other bugs)
: Trunk
: All All
: P1 major with 2 votes (vote)
: ---
Assigned To: Nobody; OK to take it and work on it
:
Mentors:
http://www.cs.waikato.ac.nz/Teaching/...
: 200860 227996 236098 244129 248741 278135 284323 285575 297615 303269 412147 (view as bug list)
Depends on: 134706
Blocks: 312372 287236 290146
  Show dependency treegraph
 
Reported: 2001-10-18 14:19 PDT by K Hopper
Modified: 2008-12-23 09:50 PST (History)
28 users (show)
dbaron: blocking1.9-
reed: wanted1.9+
bzbarsky: in‑testsuite?
See Also:
Crash Signature:
(edit)
QA Whiteboard:
Iteration: ---
Points: ---
Has Regression Range: ---
Has STR: ---


Attachments
Table cell overflow example source (32.36 KB, text/html)
2001-10-18 14:21 PDT, K Hopper
no flags Details
simplified test case (693 bytes, text/html)
2001-10-22 15:42 PDT, mike west
no flags Details
Comparative floater testcase (796 bytes, text/html)
2001-11-09 19:38 PST, Christopher Hoess (gone)
no flags Details
Same testcase as "simplified test case", but standards mode (614 bytes, text/html)
2003-11-16 10:40 PST, Boris Zbarsky [:bz]
no flags Details
More comprehensive test (1.73 KB, text/html)
2005-04-29 21:16 PDT, Eli Friedman
no flags Details
Testcase #6 (2.00 KB, text/html)
2006-09-26 21:54 PDT, Mats Palmgren (:mats)
no flags Details
Like so? (3.54 KB, patch)
2006-09-26 22:05 PDT, Mats Palmgren (:mats)
no flags Details | Diff | Splinter Review
Is this correct? (281 bytes, text/html)
2008-12-21 13:44 PST, Daniel.S
no flags Details

Description K Hopper 2001-10-18 14:19:11 PDT
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 2001-10-18 14:21:53 PDT
Created attachment 54118 [details]
Table cell overflow example source
Comment 2 Boris Zbarsky [:bz] 2001-10-18 17:01:56 PDT
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 2001-10-22 15:42:57 PDT
Created attachment 54558 [details]
simplified test case
Comment 4 mike west 2001-10-22 15:46:47 PDT
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) 2001-10-22 17:23:24 PDT
flaoater. -->attinasi
Comment 6 Christopher Hoess (gone) 2001-11-09 19:38:06 PST
Created attachment 57332 [details]
Comparative floater testcase
Comment 7 Marc Attinasi 2002-02-25 15:45:42 PST
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 2003-03-31 12:44:54 PST
attinasi will probably not work on those bugs :-(
Comment 9 Boris Zbarsky [:bz] 2003-11-14 10:46:18 PST
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-7 (review requests must explain patch) 2003-11-14 11:26:54 PST
But if it can't fit, maybe it should try to be below the float instead of next
to it?
Comment 11 Boris Zbarsky [:bz] 2003-11-14 12:36:15 PST
True... And that works with text and images.  Is the problem that we get an
incorrect MES somewhere?
Comment 12 David Baron :dbaron: ⌚️UTC-7 (review requests must explain patch) 2003-11-14 13:16:41 PST
We actually probably have an explicit quirk to force it not to wrap, or
something ugly like that.
Comment 14 Boris Zbarsky [:bz] 2003-11-16 10:28:24 PST
Er... Except none of the tables here have nowrap attributes set?
Comment 15 David Baron :dbaron: ⌚️UTC-7 (review requests must explain patch) 2003-11-16 10:34:22 PST
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-7 (review requests must explain patch) 2003-11-16 10:37:35 PST
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 [:bz] 2003-11-16 10:38:33 PST
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 [:bz] 2003-11-16 10:40:52 PST
Created attachment 135666 [details]
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-7 (review requests must explain patch) 2003-11-16 10:59:12 PST
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-7 (review requests must explain patch) 2003-11-16 11:02:59 PST
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 [:bz] 2003-12-09 23:53:00 PST
*** Bug 227996 has been marked as a duplicate of this bug. ***
Comment 22 David Baron :dbaron: ⌚️UTC-7 (review requests must explain patch) 2004-01-31 11:14:09 PST
*** Bug 200860 has been marked as a duplicate of this bug. ***
Comment 23 Boris Zbarsky [:bz] 2004-07-14 03:05:09 PDT
*** Bug 248741 has been marked as a duplicate of this bug. ***
Comment 24 Mats Palmgren (:mats) 2004-07-18 22:12:29 PDT
*** Bug 236098 has been marked as a duplicate of this bug. ***
Comment 25 Erik Fabert 2004-11-29 04:41:49 PST
*** Bug 244129 has been marked as a duplicate of this bug. ***
Comment 26 Boris Zbarsky [:bz] 2005-02-01 13:29:55 PST
*** Bug 278135 has been marked as a duplicate of this bug. ***
Comment 27 Andrew Schultz 2005-03-13 21:48:23 PST
*** Bug 284323 has been marked as a duplicate of this bug. ***
Comment 28 Steve England [:stevee] 2005-03-30 06:51:02 PST
*** Bug 285575 has been marked as a duplicate of this bug. ***
Comment 29 Eli Friedman 2005-04-29 21:14:31 PDT
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 2005-04-29 21:16:10 PDT
Created attachment 182232 [details]
More comprehensive test
Comment 31 Michal 'hramrach' Suchanek 2005-05-10 05:51:32 PDT
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 2005-05-22 12:09:05 PDT
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 [:bz] 2005-05-22 12:40:22 PDT
> 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 2005-05-22 14:27:02 PDT
> 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-7 (review requests must explain patch) 2005-05-22 14:30:46 PDT
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 [:mwargers] (not working for Mozilla) 2005-06-14 00:15:53 PDT
*** Bug 297615 has been marked as a duplicate of this bug. ***
Comment 37 Boris Zbarsky [:bz] 2005-11-15 09:28:09 PST
*** Bug 303269 has been marked as a duplicate of this bug. ***
Comment 38 Mats Palmgren (:mats) 2006-09-26 21:54:17 PDT
Created attachment 240278 [details]
Testcase #6
Comment 39 David Baron :dbaron: ⌚️UTC-7 (review requests must explain patch) 2006-09-26 22:02:20 PDT
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 (:mats) 2006-09-26 22:05:27 PDT
Created attachment 240283 [details] [diff] [review]
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 (:mats) 2006-09-26 22:09:56 PDT
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) (Exited; email my personal email if necessary) 2006-09-26 22:32:33 PDT
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-7 (review requests must explain patch) 2006-09-26 22:38:50 PDT
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) (Exited; email my personal email if necessary) 2007-09-14 02:47:13 PDT
Comment on attachment 240283 [details] [diff] [review]
Like so?

we need a new patch per David's comment
Comment 45 Mats Palmgren (:mats) 2008-01-13 03:03:37 PST
*** Bug 412147 has been marked as a duplicate of this bug. ***
Comment 46 Robert O'Callahan (:roc) (Exited; email my personal email if necessary) 2008-04-16 20:33:37 PDT
This is fixed, probably via bug 134706.
Comment 47 Daniel.S 2008-12-21 13:44:25 PST
Created attachment 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?
Comment 48 Andres Rios 2008-12-22 16:27:46 PST
(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 2008-12-22 16:28:28 PST
(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 2008-12-23 09:40:18 PST
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-7 (review requests must explain patch) 2008-12-23 09:50:11 PST
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.

Note You need to log in before you can comment on or make changes to this bug.