26695 - [FLOAT] floated empty <select> confuses tables

Status: VERIFIED WORKSFORME

(Core :: Layout: Tables, defect, P4)

Description

[Syn.Terra]

After some rigorous testing I found that the ALIGN attribute can cause entire
TD's to "hide" their contents. I'm not sure if the ALIGN attribute is actually
to blame, but the bug appeared when the ALIGN attribute was in place but not
when it was absent.

The above page is an example of where I first saw the bug: Wired News. the page
is a stripped down version (ie. extraneous banners and comments removed) but the
bug should be evident. When the page loads, the main table should show its
contents, and then they disappear.

If you play with the source like I did you can see exactly where the bug
happens. If you comment out everything between lines 70 and 254 (I put markers
to indicate where) then the contents will show. Also, if you get rid of the
ALIGN="LEFT" attribute on line 72, all the contents will render perfectly, but
the TD will be beneath the side column.

I tested this on a Win98 box running M13, build ID 2000012520. If you compare
the results of the pages between Mozilla and Communicator (I used 4.6) you can
see exactly how it *should* look and how it *does* look.

Comment 1

[Mats Palmgren (inactive)]

Attachment: Testcase

Comment 2

[karnaze (gone)]

I think I've seen a similar bug before involving a floated nested table and 
assigned it to Kipp's bug list after some analysis. 

Comment 3

[buster]

mine! mine mine mine!  all mine!  whoo-hoo!

Comment 4

[buster]

floater problems to M16

Comment 5

[buster]

test against my local tree, may already be fixed.

Comment 6

[buster]

the only way I can reproduce this is with a select that contains no options.  
That's a pretty rare thing, so I'm going to push it off until M18. 

Comment 7

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

Right now I'm just seeing the inner table stick out of the outer table.  Is this 
a table bug?  Karnaze?  (I could see it being a block bug too...)

Comment 8

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

Actually, what I'm seeing now is just bug 27997.

Comment 9

[Hixie (not reading bugmail)]

The problem appears to be that the outer table is not taking the inside floated
table-with-form into account when sizing itself around the inner non-floated
table. Or something.

QA: A better testcase would be nice...

-> Future...

Comment 10

[Jesse Ruderman]

Nothing's disappearing for me, 2000 091808 (before bug 52663 fix)

Comment 11

[Jacob Kjome]

Nothing is disappearing, however the inner table's width should not break out of
the outer table no matter what.  I don't care if you set the outer table at a
width of 1.  The outer table should size out to whatever the inner table needs
either fit its contents in itself and/or display itself in its stated width.

I'm not sure about all the css rules, but this isn't using css and tables
contain things.  Things simply don't break out of the the borders of tables.  if
that behavior is needed, a <div> ought to be used.  Tables are structural and
should be counted on as such.

Jake

Comment 12

[Hixie (not reading bugmail)]

HTML has no rendering rules.
We are a CSS browser. The CSS table rendering rules are described here:
   http://www.w3.org/TR/REC-CSS2/tables.html

We still need a smaller testcase (which I will make, eventually, after N6 RTM, 
if no-one else does in the meantime).

Comment 13

[Hixie (not reading bugmail)]

It appears to be a combination of <select> elements not correct propagating
their size when their parent is floated, and <table> elements not sizing 
correctly when they contain nested tables.

New attachment coming up, but it isn't much better than the existing one.

cc'ing rods since I can't get this to happen if I remove the <select> element.

Comment 14

[Hixie (not reading bugmail)]

Attachment: Self explanatory testcase (nested tables and a floated empty <select>)

Comment 15

[Hixie (not reading bugmail)]

It turns out that the bug also happens if the <select> is floated itself -- and
it _doesn't_ happen if the <select> has an options! Could it be that the 
<select> misreports its size somewhere when it is empty?

Comment 16

[Hixie (not reading bugmail)]

Note that an incremental reflow fixes it (change of font size, for instance).

Comment 17

[Hixie (not reading bugmail)]

Has something changed in this area of the code? It seems to be working now.

Comment 18

[Kevin McCluskey (gone)]

Build reassigning Buster's bugs to Marc.

Comment 19

[Christopher Hoess (gone)]

Resolving WORKSFORME.

Comment 20

[Amarendra Hanumanula]

 Looks good to me. Marking verified