99461 - floated boxes drawn over text

Status: RESOLVED FIXED

(Core :: Layout, defect, P2)

Description

[yoav]

the dhtml boxes are drwan over the text instead of being drawn to the right (see
in ie).
build 2001091203

Comment 1

[Boris Zbarsky [:bzbarsky]]

Confirming. There seems to be no positioning going on, no CSS involved, no
floating involved. Quite odd.

Seeing this on Linux as well...

Comment 2

[Kevin McCluskey (gone)]

Need reduced test case

Comment 3

[R.K.Aa.]

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

Comment 4

[Chu Alan]

Attachment: Reduced testcase.

Reduced testcase.

Works good in Netscape, fails in mozilla.

Comment 5

[Chu Alan]

i think the problem is here because mozilla does not do "collision" check for
two overlapping table that has one left-aligned and right-aligned, so when 2
table is too large, they will become overlapped, or when one of the table use
with="100%", mozilla will give the 100% of the whole document area, and it won't
exclude the width of another table.

The testcase works good in netscape on linux, but fails on mozilla, linux build
200112108.

Comment 6

[Boris Zbarsky [:bzbarsky]]

ccing waterson; looks like a float issue....

Comment 7

[Boris Zbarsky [:bzbarsky]]

Also, setting QA to Ian.  I think that our behavior may actually be correct for 
floaters per the CSS2 spec....

Comment 8

[Chris Waterson]

Investigating...

Comment 9

[Chris Waterson]

Attachment: more test-case tinkering

Converted one of the tables to a <div>; demonstrate that the table is allowed
to flow to its maximum width regardless of whether it's left- or right-
floated.

Comment 10

[Chris Waterson]

Attachment: mono-a-mono

IE constrains the table's width based on the space taken up by the float; we
don't.

Comment 11

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

IE's behavior here is really ridiculous.  Do we really need to imitate it?

Comment 12

[Chris Waterson]

Why is IE's behavior ridiculous? (I have no personal opinion on this, I'm just
curious.)

Comment 13

[Hixie (not reading bugmail)]

IE is wrong.

However I don't understand why the floats are overlapping. Shouldn't the second
float in both cases go under the first float? I think we already do that
correctly for the two-div case, so it's probably a bug in table code.

Comment 14

[Chris Waterson]

We do, in fact, get the two-<div> case `right', yet we get it `right'
differently than IE does. (IE's behavior with both a right- and left-floated
<div> is almost identical to that of a right-floated <table> with a left-floated
<div>; that is, the text in the <div> is wrapped so that both fit on the same
line. Sigh.)

I'll fix this so that we behave identically whether floating a <table> or a
<div>; i.e., push the right-float down to the next line.

Comment 15

[Chris Waterson]

Aha! More buster fun. It looks like this ``fix'' has to do with bug 37657, which
was later un-fixed for <div>s by dbaron in bug 43806. I suspect what buster was
trying to do was to implement the IE/Nav4-like behavior where the float is
wrapped and placed on the same line if there is still space available on the
line. Anyway, this one is easy to ``fix'' by unfixing buster's change all the
way. What will we break, I wonder?

Comment 16

[Chris Waterson]

Attachment: diff -uw, always check if there's space available regardless of display type

Comment 17

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

Comment on attachment 63334 [details] [diff] [review]
diff -uw, always check if there's space available regardless of display type

r=dbaron  I'd be interested to know how many pages really have problems with
this patch -- the bug buster fixed didn't seem to mention more than one page.

Comment 18

[Chris Waterson]

Attachment: what buster probably meant

Of course, attachment 63334 [details] [diff] [review] doesn't fix the god-awful layout of the original
test URL (it probably makes it worse, in fact).

Here's a more aggressive patch, that attempts to emulate older browsers when in
compatibility mode. This patch will ``fix'' the original test case so that it
lays out comparably to IE and Nav4. It does this by flowing the floater in the
remaining available space, rather than at the full width of the containing
block.

If we want to consider this patch, it still needs some work: it looks like
there is an off-by-one error (e.g., > instead of >=) lurking somewhere that
makes it screw up attachment 63326 [details]. Also, were we to use this patch, we may
want to revert to the behavior where we'd iterate when the floater couldn't be
placed on the current line: that would yield reasonable layout if the float
couldn't be placed because of a MES that was too wide, for example. (Or we
could just say ``screw it'' and leave the float skinny, maybe that's how Nav4
and IE did it.)

Comment 19

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

Ugh.  Could you at least make it tables-only?

Comment 20

[Chris Waterson]

Well, a quirk is a quirk: both Nav4 and IE do the same thing with <div>s. So if
the goal is to emulate, we ought to emulate. I'm also okay with tossing this
over the transom altogether. (But I'll be a donut that this this will come back
as a `topembed' in the future. We can always wait and worry about it then, of
course.)

FWIW, bug 117641 is almost certainly related to this bug, but is not fixed with
attachment 63342 [details] [diff] [review].

Comment 21

[Chris Waterson]

On the original test case (attachment 62709 [details]), Win32 IE6 and and Mac IE5.1 both
squeeze the right-floated table to fit. On my modified test case (attachment
63324 [details]), Win32 IE6 wraps the floated tables to fit (as do IE5.x and Nav4).
Interestingly, Mac IE 5.1 does _not_ wrap the floated table to fit in the second
test case.

In fact, Mac IE 5.1 treats `align="left"' differently from `style="float:
left;"'. Altering the original test case to use the `style' attribute to
left-float the table (instead of the `align' attribute) triggers the push.

So where do we stand? dbaron has essentially said that he's fine with WONTFIXing
this bug, perhaps after applying attachment 63334 [details] [diff] [review] to undo broken table-specific
hackery. (This will, unfortunately, make the situation worse for this specific
page, and other like it; e.g., bug 117641.) I'm fairly certain Hixie feels the
same way.

I'm worried about compatibility issues, but don't really want to go tilting at
windmills if there are only a handful of pages out there that are affected by
this problem.

Marc, you were concerned about floater issues last time we talked: how many of
the float bugs remaining on your plate might be related to this?

Comment 22

[Hixie (not reading bugmail)]

I'm all for checking in attachment 63334 [details] [diff] [review], yes. We could wait to see how many
dups we get and reconsider this later.

Personally though I'm of the opinion that we should stop adding quirks, and if
we ever want to add a quirk we should remove another one first.

Note that the CSSWG (including Opera and IE developers) agreed a few months ago
that we should not have the behaviour IE has of fitting floats in narrow spaces.

Comment 23

[Chris Waterson]

Well, technically, we'd be making a quirk work properly, not adding a new one.

Comment 24

[Marc Attinasi]

I agree that attachment 63334 [details] [diff] [review] is good to apply.  Looking at one of the comments
in the bug buster was trying to fix makes me think he was acting on heresay
rather than direct evidence: see
http://bugzilla.mozilla.org/show_bug.cgi?id=37657#c7  I don't know how
knowledgable his web-designer friends were...

As for how this relates to the remaining float bugs on my plate, I am no sure. I
have not been looking at them in any detail lately, certainly not to the point
where I understand their root causese - sorry.

sr=attinas on attachment 63334 [details] [diff] [review], BTW.

Comment 25

[Chris Waterson]

Okay, I've checked in attachment 63334 [details] [diff] [review]. I'm not going to close this bug, because
the page still looks horrible: FUTURE-ing and marking [WONTFIX?] in the status
bar. We can see how many of these pile up, and reconsider working on attachment
63342 [review] if it turns out there are lots of them.

Comment 26

[Chris Waterson]

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

Comment 27

[John Morrison]

> What will we break, I wonder?

http://www.tomshardware.com/
http://cowtools.mcom.com/perf/content/base/www.tomshardware.com/index.html

(reload and/or narrow browser window, if you don't see several pages of grey 
background when you first load the live site).

Comment 28

[Alexandru Savulov]

please see analysis on bug 122200

(i have a fix for both bugs, will attach it on bug 122200)

Comment 29

[Alexandru Savulov]

fixed by fix for bug 122200