226637 - Wrong table width when the table has "table-layout:fixed;" and fixed width and larger width cells than the table width.

Status: RESOLVED FIXED

(Core :: Layout: Tables, defect)

Description

[Masayuki Nakano [:masayuki] (he/him)(JST, +0900)]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.6b) Gecko/20031122
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.6b) Gecko/20031122

if table has following style rules and fixed width.
table{
    table-layout: fixed;
    border-collapse: separate;
}

this table's cells are overflow from the table.

test cases here.
Standard: http://bugzilla.mozilla.gr.jp/attachment.cgi?id=1897&action=view
Quirks:   http://bugzilla.mozilla.gr.jp/attachment.cgi?id=1898&action=view

there test cases's last 4 case is wrong.

Reproducible: Always

Steps to Reproduce:
1. see above test cases.
2.
3.

Actual Results:  
table cell overflow the table.

Expected Results:  
table cell should not overflow the table.

Spec of CSS2.1
http://www.w3.org/TR/CSS21/tables.html#fixed-table-layout

> The width of the table is then the greater of the value of the 'width'
property for the table element and the sum of the column widths (plus cell
spacing or borders).

this bug comes bugzilla-jp
http://bugzilla.mozilla.gr.jp/show_bug.cgi?id=3500

and we tested with WinXP and Linux.

Comment 1

[HARUNAGA Hirotoshi]

Confirmed also on Mac.
Marking New and changing to All.

Opera 7.22 doesn't have this problem.

Comment 2

[Boris Zbarsky [:bzbarsky]]

So correct layout here would be for the blue cell to have width 0 and for the
text in it to overflow, right?

Comment 3

[Masayuki Nakano [:masayuki] (he/him)(JST, +0900)]

I don't know correct result this problem...(in Spec)

I can say only one that table cell should not overflow the table.

But UA should be User-friendly.
So I think that UA should treat first cell has "width:auto".
like the 4th test case.

Comment 4

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

CSS2.1 says (in http://www.w3.org/TR/CSS21/tables.html#fixed-table-layout ):

The width of the table is then the greater of the value of the 'width' property
for the table element and the sum of the column widths (plus cell spacing or
borders). If the table is wider than the columns, the extra space should be
distributed over the columns.

Comment 5

[Bernd]

taking

Comment 6

[Masayuki Nakano [:masayuki] (he/him)(JST, +0900)]

David Baron:
Yes, I know that.
See comment #0.

I don't know that the second cell should be {width:0} or {width:auto}.

Comment 7

[Bernd]

Attachment: rev0

Comment 8

[Hideo Saito]

I confirmed that the cell did not overflow the table by applying the patch of
rev0. However, the new problem of this patch was found. Here is our test case.

http://bugzilla.mozilla.gr.jp/attachment.cgi?id=1895&action=view

When a button of 'grow' is pushed and table width spreads, the border line of
the table moves up and down.

We report the new bug which appears in the above-mentioned test case.
We think that the appearance of a vertical scroll bar is a bug.
The following patch has the effect of disappearing a vertical scroll bar.

http://bugzilla.mozilla.gr.jp/attachment.cgi?id=1901&action=view

Comment 9

[Bernd]

Saito san,

thanks for the nifty testcase, but I will certainly not follow your patch. I
think it is wrong. Your testscase/patch shows that something with the
overflowarea is going wrong, so the right thing to do is  to get the overflow
area / desired size correctly rather than to change the scrollbar logic.

Comment 10

[Masayuki Nakano [:masayuki] (he/him)(JST, +0900)]

Bernd:

See Bug 228385.
I think that this bug blocks it.

Comment 11

[Bernd]

Attachment: patch

Comment 12

[Bernd]

Comment on attachment 157861 [details] [diff] [review]
patch

review hint:
-	 if (0 == availColWidth)  availColWidth  = NS_UNCONSTRAINEDSIZE;
-	 if (0 == availCellWidth) availCellWidth = NS_UNCONSTRAINEDSIZE;
 are the evil lines, the whole patch dances around removing them

Comment 13

[Bernd]

Comment on attachment 157861 [details] [diff] [review]
patch

this patch will not fix but further regress
http://bugzilla.mozilla.org/attachment.cgi?id=158544&action=view

Comment 14

[Bernd]

per discussion with shaver on irc. I don't understand what "me" is thinking why
this should block aviary. Is this a recent regression: NO, the problem is old
very old. Is there a working patch for trunk also: NO. Is this a crash bug.
Again: NO.

Comment 15

[Bernd]

Attachment: patch

Comment 16

[Bernd]

Comment on attachment 162390 [details] [diff] [review]
patch

I runned the regression data and it showed several 
framestate mismatch 0x88000004 vs 0x80000004
which is good as this indicates the cells that wished a second reflow got one
(http://lxr.mozilla.org/seamonkey/source/layout/html/table/src/nsTableCellFrame
.h#58)

Comment 17

[Boris Zbarsky [:bzbarsky]]

I'll try to look at this in the next few days, but shouldn't table cell be fixed
to not cause the false positives by implementing GetDebugStateBits()
appropriately?  See
http://lxr.mozilla.org/seamonkey/source/layout/base/public/nsIFrameDebug.h#69 

Comment 18

[Bernd]

No, this are not false positives, the difference indicates that we are doing a
thing right, which we previously did not. A table cells that sets the flag need
second reflow should be reflowed another time, without this patch this did not
happen in a couple of cases.

Comment 19

[Boris Zbarsky [:bzbarsky]]

Comment on attachment 162390 [details] [diff] [review]
patch

r+sr=bzbarsky

Comment 20

[Bernd]

fix checked in

Comment 21

[Bernd]

.

Comment 22

[Bernd]

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