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

RESOLVED WORKSFORME

Status

()

Core
Layout: Block and Inline
P1
major
RESOLVED WORKSFORME
16 years ago
9 years ago

People

(Reporter: K Hopper, Unassigned)

Tracking

(Blocks: 1 bug, {testcase})

Trunk
testcase
Points:
---
Dependency tree / graph
Bug Flags:
blocking1.9 -
wanted1.9 +
in-testsuite ?

Firefox Tracking Flags

(Not tracked)

Details

(Whiteboard: [reflow-refactor], URL)

Attachments

(8 attachments)

(Reporter)

Description

16 years ago
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.
(Reporter)

Comment 1

16 years ago
Created attachment 54118 [details]
Table cell overflow example source
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.
Status: UNCONFIRMED → NEW
Ever confirmed: true

Comment 3

16 years ago
Created attachment 54558 [details]
simplified test case

Comment 4

16 years ago
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

16 years ago
flaoater. -->attinasi
Assignee: karnaze → attinasi

Updated

16 years ago
Target Milestone: --- → mozilla1.0.1
Created attachment 57332 [details]
Comparative floater testcase

Updated

16 years ago
Keywords: testcase

Comment 7

16 years ago
Moving Mozilla 1.01 bugs to 'future' milestone with priority P1

I will be pulling bugs from 'future' milestones when scheduling later work.
Priority: -- → P1
Target Milestone: mozilla1.0.1 → Future

Comment 8

14 years ago
attinasi will probably not work on those bugs :-(
Assignee: attinasi → table
QA Contact: amar → madhur
Target Milestone: Future → ---

Updated

14 years ago
Target Milestone: --- → Future
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.
Status: NEW → RESOLVED
Last Resolved: 14 years ago
Resolution: --- → INVALID
But if it can't fit, maybe it should try to be below the float instead of next
to it?
True... And that works with text and images.  Is the problem that we get an
incorrect MES somewhere?
Status: RESOLVED → REOPENED
Resolution: INVALID → ---
Summary: Table cell overflow suspected. → table after left float is next to float even when it doesn't fit
We actually probably have an explicit quirk to force it not to wrap, or
something ugly like that.
Status: REOPENED → NEW

Comment 13

14 years ago
The code to be ashamed off is at
http://lxr.mozilla.org/seamonkey/source/content/html/content/src/nsHTMLTableCellElement.cpp#490
Er... Except none of the tables here have nowrap attributes set?
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".
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.
But in this case the second table is _not_ floated, so that code shouldn't
apply, should it?  Agreed that that quirk is ugly.  :(
Created attachment 135666 [details]
Same testcase as "simplified test case", but standards mode

This shows the bug too.  So this ain't a quirk.
Ah, right.  So it's basically the same as: 
http://dbaron.org/css/test/2003/float-and-overflow/outside-scroll
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.
*** Bug 227996 has been marked as a duplicate of this bug. ***
*** Bug 200860 has been marked as a duplicate of this bug. ***
Blocks: 236098
*** Bug 248741 has been marked as a duplicate of this bug. ***

Updated

13 years ago
No longer blocks: 236098
*** Bug 236098 has been marked as a duplicate of this bug. ***

Comment 25

13 years ago
*** Bug 244129 has been marked as a duplicate of this bug. ***
*** Bug 278135 has been marked as a duplicate of this bug. ***

Comment 27

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

Updated

12 years ago
Blocks: 287236
*** Bug 285575 has been marked as a duplicate of this bug. ***

Comment 29

12 years ago
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

12 years ago
Created attachment 182232 [details]
More comprehensive test
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.
Blocks: 290146

Comment 32

12 years ago
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."
> 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

12 years ago
> 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.
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.)
*** Bug 297615 has been marked as a duplicate of this bug. ***
*** Bug 303269 has been marked as a duplicate of this bug. ***
Blocks: 312372

Updated

11 years ago
Assignee: layout.tables → nobody
Component: Layout: Tables → Layout: Block and Inline
OS: Linux → All
QA Contact: madhur → layout.block-and-inline
Summary: table after left float is next to float even when it doesn't fit → block-level elements after left float is next to float even when it doesn't fit
Target Milestone: Future → ---
Created attachment 240278 [details]
Testcase #6
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.
Summary: block-level elements 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
Whiteboard: [reflow-refactor]
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.
Attachment #240283 - Flags: review?(roc)
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.
You're clearing all floats. Do you really want to do that? Couldn't the block fit next to a narrow float further down?
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).
Flags: blocking1.9?
Flags: blocking1.9? → blocking1.9-
Whiteboard: [reflow-refactor] → [wanted-1.9][reflow-refactor]
Comment on attachment 240283 [details] [diff] [review]
Like so?

we need a new patch per David's comment
Attachment #240283 - Flags: review?(roc)

Updated

10 years ago
Duplicate of this bug: 412147
Flags: wanted1.9+
Whiteboard: [wanted-1.9][reflow-refactor] → [reflow-refactor]
This is fixed, probably via bug 134706.
Status: NEW → RESOLVED
Last Resolved: 14 years ago9 years ago
Resolution: --- → WORKSFORME
Flags: in-testsuite?
Depends on: 134706

Comment 47

9 years ago
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

9 years ago
(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

9 years ago
(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

9 years ago
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.
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.
You need to log in before you can comment on or make changes to this bug.