368600 - Table with table-layout: fixed has unconstrained width even when width specified on cell

Status: RESOLVED FIXED

(Core :: Layout: Tables, defect)

Description

[Uri Bernstein]

Attachment: testcase

In the URL above, notice that below the banner, the form controls on the left and blue/red image on the right are adjacent to the window's edges, rather than being constrained to the same width as the rest of the page.

The attached minimized testcase demonstrates that for a table with style="table-layout: fixed;", the table width is unconstrained even though it's (only) cell has a specified width.

This is a reflow-refactoring regression.

Bug 363316, bug 363443 and/or bug 364989 might be related, although this doesn't seem like an exact duplicate of either of them.

Comment 1

[Bernd]

why should the table in the testcase be 100px wide the CSS2.1 spec does not say so.

Comment 2

[Uri Bernstein]

(In reply to comment #1)
> why should the table in the testcase be 100px wide the CSS2.1 spec does not say
> so.
> 

The CSS2.1 spec says[1] that for fixed table layout, a table width value of "auto" (as in this case), "means use the automatic table layout algorithm". Under the automatic table layout algorithm, the width of the table should be 100px (as Mozilla shows when I change the "table-layout" property to "auto").

It's true that the standard also says that "However, if the table is a block-level table ('display: table') in normal flow, a UA may (but does not have to) use the algorithm of 10.3.3 to compute a width and apply fixed table layout even if the specified width is 'auto'." But:

1. I don't see any reason that we should be taking this option, given that apparently no other browser is doing this (the table is 100px wide on IE7 and Safari).

2. Even if we do take that option, it's not clear that it means the table should end up taking up the entire width of its container. The standard says "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". But it's not clear to me that "the value of the 'width' property" should be interpreted to mean "the computed width", in the case where the specified width is "auto".

[1] http://www.w3.org/TR/CSS21/tables.html#fixed-table-layout

Comment 4

[Bernd]

Attachment: patch

I do not understand, why we all over sudden stopped to require a width. We did that for years and it fits the spec. At least as long as we return otherwise nscoord_MAX as the preferred width of a fixed table we should make the tables without a width auto-layout. 
<Off topic>I have big difficulties to understand what part of the CSS spec requires that tables return nscoord_MAX when they should shrink wrap. Enlightenment is greatly wellcome</Off topic>

Comment 5

[Peter Snyder]

I'm not a code contributor, so take this suggestion with a grain of salt, but it seems strange to change from the FF2 behavior.  If you keep the new behavior, standards compliant websites will break while they look fine in other browsers, which hurts users who can't view the site properly in FF, hurts site developers who have to change their sites, and hurts the FF name since it looks to users like FF is broken while other browsers work. 

Comment 6

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

CSS2.1 says:

  The table's width may be specified explicitly with the 'width'
  property. A value of 'auto' (for both 'display: table' and 'display:
  inline-table') means use the automatic table layout algorithm.
  However, if the table is a block-level table ('display: table') in
  normal flow, a UA may (but does not have to) use the algorithm of
  10.3.3 to compute a width and apply fixed table layout even if the
  specified width is 'auto'.

I thought the last sentence was added to let us be compatible with IE (and because there was no reason not to allow it).  Doesn't IE allow fixed layout even when width is auto?

Comment 7

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

Attachment: some additional testcases

Comment 8

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

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

So this patch moves us away from compatibility with IE, except for the one case where all the cells in the table have specified widths.  What we should really do, I think, is handle that case in the ComputeAutoSize code for fixed layout tables, or something like that.  But if we don't have time to do that for 1.9, we probably should do this, so that we're at least in the state where we were in 1.8.

So r+sr+a=dbaron, but please make sure there's a bug filed on undoing this and fixing the size computation.

Comment 9

[mdew]

patch seems to be working well, no issues. this also brings Firefox compatibility to IE and Opera. 

Comment 10

[Stuart Parmenter]

can this be marked fixed?

Comment 11

[Uri Bernstein]

(In reply to comment #10)
> can this be marked fixed?
> 

No, the patch was never checked in.

Comment 12

[Reed Loden [:reed]]

Just a reminder to please commit this by Monday if you want to get it in before beta. Otherwise, approval1.9+ will be revoked, and you will need to re-request it after M9 if you still want to land the patch. If you would like somebody else to commit this for you, please add the "checkin-needed" keyword.

Comment 13

[mdew]

can we get this checked in?

Comment 14

[Reed Loden [:reed]]

Checking in layout/tables/nsTableFrame.cpp;
/cvsroot/mozilla/layout/tables/nsTableFrame.cpp,v  <--  nsTableFrame.cpp
new revision: 3.704; previous revision: 3.703
done

Note that the last part of comment #8 was never followed-up: "please make sure there's a bug filed on undoing this and fixing the size computation."

Comment 15

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

Filed bug 400776.