floated boxes drawn over text




17 years ago
4 years ago


(Reporter: stakadush, Assigned: waterson)


Dependency tree / graph

Firefox Tracking Flags

(Not tracked)


(Whiteboard: [WONTFIX?], URL)


(3 attachments, 2 obsolete attachments)



17 years ago
the dhtml boxes are drwan over the text instead of being drawn to the right (see
in ie).
build 2001091203
Confirming. There seems to be no positioning going on, no CSS involved, no
floating involved. Quite odd.

Seeing this on Linux as well...

Ever confirmed: true
OS: Windows 2000 → All
Need reduced test case
Keywords: qawanted
Target Milestone: --- → mozilla1.0

Comment 3

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


17 years ago
Target Milestone: mozilla1.0 → mozilla1.2

Comment 4

17 years ago
Created attachment 62709 [details]
Reduced testcase.

Reduced testcase.

Works good in Netscape, fails in mozilla.

Comment 5

17 years ago
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
ccing waterson; looks like a float issue....
Also, setting QA to Ian.  I think that our behavior may actually be correct for 
floaters per the CSS2 spec....
QA Contact: petersen → ian

Comment 8

17 years ago
Assignee: attinasi → waterson
Priority: -- → P2
Summary: dhtml boxes drawn over text → floated boxes drawn over text
Target Milestone: mozilla1.2 → mozilla0.9.8


17 years ago

Comment 9

17 years ago
Created attachment 63324 [details]
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-

Comment 10

17 years ago
Created attachment 63326 [details]

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


17 years ago
Blocks: 117641

Comment 12

17 years ago
Why is IE's behavior ridiculous? (I have no personal opinion on this, I'm just
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

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

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

17 years ago
Created attachment 63334 [details] [diff] [review]
diff -uw, always check if there's space available regardless of display type
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.
Attachment #63334 - Flags: review+

Comment 18

17 years ago
Created attachment 63342 [details] [diff] [review]
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

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 20

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

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

Comment 21

17 years ago
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?
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

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


17 years ago
Blocks: 118426


17 years ago
No longer blocks: 118426

Comment 24

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

17 years ago
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.
Whiteboard: [WONTFIX?]
Target Milestone: mozilla0.9.8 → Future


17 years ago
No longer blocks: 117641

Comment 26

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

Comment 27

17 years ago
> What will we break, I wonder?


(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

17 years ago
please see analysis on bug 122200

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


17 years ago
No longer blocks: 122200


17 years ago
Depends on: 122200


17 years ago
Blocks: 100552
Attachment #63334 - Attachment is obsolete: true
Attachment #63342 - Attachment is obsolete: true


17 years ago
No longer blocks: 119654


17 years ago
Blocks: 119654

Comment 29

17 years ago
fixed by fix for bug 122200
Last Resolved: 17 years ago
Resolution: --- → FIXED
Keywords: qawanted
You need to log in before you can comment on or make changes to this bug.