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.
Created attachment 54118 [details]
Table cell overflow example source
The page has:
<table align="left" width="95%">
<!-- Header in here -->
<!-- body in here -->
This problem does _not_ occur if the floater is a div. Ccing waterson.
Created attachment 54558 [details]
simplified test case
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
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?
Created attachment 57332 [details]
Comparative floater testcase
Moving Mozilla 1.01 bugs to 'future' milestone with priority P1
I will be pulling bugs from 'future' milestones when scheduling later work.
attinasi will probably not work on those bugs :-(
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.
But if it can't fit, maybe it should try to be below the float instead of next
True... And that works with text and images. Is the problem that we get an
incorrect MES somewhere?
We actually probably have an explicit quirk to force it not to wrap, or
something ugly like that.
The code to be ashamed off is at
Er... Except none of the tables here have nowrap attributes set?
The quirk I was thinking of was:
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
Although it's only the quirk-within-a-quirk at
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:
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
*** Bug 227996 has been marked as a duplicate of this bug. ***
*** Bug 200860 has been marked as a duplicate of this bug. ***
*** Bug 248741 has been marked as a duplicate of this bug. ***
*** Bug 236098 has been marked as a duplicate of this bug. ***
*** Bug 244129 has been marked as a duplicate of this bug. ***
*** Bug 278135 has been marked as a duplicate of this bug. ***
*** Bug 284323 has been marked as a duplicate of this bug. ***
*** Bug 285575 has been marked as a duplicate of this bug. ***
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.
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
Since the spec does not say anything clearly at least losing parts of content
should be avoided.
The CSS2.1 spec is *completely* clear on this issue. I'm surprised this bug has
gone unfixed for almost 4 years:
"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.
> 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
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. ***
Created attachment 240278 [details]
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.
Created attachment 240283 [details] [diff] [review]
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
Comment on attachment 240283 [details] [diff] [review]
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).
Comment on attachment 240283 [details] [diff] [review]
we need a new patch per David's comment
*** Bug 412147 has been marked as a duplicate of this bug. ***
This is fixed, probably via bug 134706.
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?
(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
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.
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.