377040 - Text wrapped in second table cell when first table cell has width: 1px

Status: RESOLVED WONTFIX

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

Description

[Martijn Wargers (dead)]

See upcoming testcase, the text in the table should not be wrapped.
This regressed between 2007-03-19 and 2007-03-20:
http://bonsai.mozilla.org/cvsquery.cgi?treeid=default&module=all&branch=HEAD&branchtype=match&dir=&file=&filetype=match&who=&whotype=match&sortby=Date&hours=2&date=explicit&mindate=2007-03-19+04&maxdate=2007-03-20+09&cvsroot=%2Fcvsroot
I think a regression from bug 363874.

Comment 1

[Martijn Wargers (dead)]

Attachment: testcase

Comment 2

[Martijn Wargers (dead)]

Attachment: reference rendering

Comment 3

[Bernd]

Just a side note opera does wrap (IE7 not)

Comment 4

[Martijn Wargers (dead)]

Well, the issue I saw with the site is fixed. It was fixed between 2007-08-02 and 2007-08-03. I think it was fixed by bug 379361.
The testcase (which I derived from the site in question) still shows the difference in rendering, though.

Comment 5

[Daniel Holbert [:dholbert]]

The bug shown by the testcase has to do with how nsTableColFrame::AddCoords() works.

Basically, Trunk will ignore a cell's preferred width if another cell in the same column has a specified width.  In our testcase, this is happening at line 197, because the specified-width row comes first. (But it also could happen at line 193, in a case with the rows reversed, i.e. with the specified-width row coming second.)

This behavior sort of makes sense, in the spirit of honoring specified-widths as best as we can, but I guess it's not what we've done in the past.  Maybe we need to remove lines 193 and 197?  Looking into that possibility (and also what the spec says in more detail)...

Snippet:
192    if (aHasSpecifiedCoord && !mHasSpecifiedCoord) {
193      mPrefCoord = mMinCoord;
194      mHasSpecifiedCoord = PR_TRUE;
195    }
196    if (!aHasSpecifiedCoord && mHasSpecifiedCoord) {
197      aPrefCoord = aMinCoord; // NOTE: modifying argument
198    }

links to source:
http://mxr.mozilla.org/seamonkey/source/layout/tables/BasicTableLayoutStrategy.cpp#303
http://mxr.mozilla.org/seamonkey/source/layout/tables/nsTableColFrame.h#197

Comment 6

[Daniel Holbert [:dholbert]]

> Maybe we need to remove lines 193 and 197?  

I take that back -- we definitely need line 193 and 197 so that cells will respect specified widths on their "column" elements. (see upcoming testcases)

Comment 7

[Daniel Holbert [:dholbert]]

Attachment: newtest 1: no spec-widths

Comment 8

[Daniel Holbert [:dholbert]]

Attachment: newtest 2: cell spec-width

Comment 9

[Daniel Holbert [:dholbert]]

Attachment: newtest 3: col spec-width

Comment 10

[Daniel Holbert [:dholbert]]

Attachment: newtest 4: col & cell spec-width

Comment 11

[Daniel Holbert [:dholbert]]

Here's a chart of which of the 4 "newtests" wrap on Branch vs Trunk.
 + = wrap
 - = no wrap

              Branch     Trunk
1 (none)        -          -
2 (cell)        -          +
3 (col)         +          +
4 (cell&col)    +          +

Comment 12

[Daniel Holbert [:dholbert]]

(In reply to comment #5)
> what the spec says

The bit of the CSS Spec about table column widths isn't very helpful.
  http://www.w3.org/TR/2007/CR-CSS21-20070719/tables.html#auto-table-layout

But according to dbaron's proposal table-layout spec, Trunk and AddCoords are doing the right thing, whereas Branch is wrong.
  http://dbaron.org/css/intrinsic

dbaron's proposal spec has this definition of column constrained-ness:
  A column is constrained if the column group (if any), the column (if any),
  or __any of the cells__ in the column has a computed 'width' that is not
  'auto', and is not a percentage.

So, in our testcase, the column is constrained because one of its cells has a specified width.

Moreover, the "constrained-ness" of the column affects how we calculate the "outer intrinsic preferred width of a table cell" for each of its cells.  From dbaron's proposal spec:

   The outer intrinsic preferred width of a table cell in a 
   constrained column is 
     max('min-width', min('max-width', max('width', intrinsic minimum width)))

This bug's original testcase uses a *constrained* column, and the max(...) expression above will evaluate to the cell's intrinsic minimum width. (which is why the table ends up as wide as the cell's min-width).

So, I'd say this isn't a Trunk bug, with respect to the current version of dbaron's table spec.

dbaron, any thoughts?

Comment 13

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

Isn't this one of the cases where WinIE behaves differently depending on the order of the rows?  I want to avoid row-order dependencies, and I think this behavior is preferred.

Comment 14

[Daniel Holbert [:dholbert]]

Attachment: testcase with reversed row-order

Comment 15

[Daniel Holbert [:dholbert]]

(In reply to comment #13)
> Isn't this one of the cases where WinIE behaves differently depending on the
> order of the rows?

Yes, it is -- IE7 doesn't wrap the original testcase (attachment 261148 [details]), but it does when we reverse the row order (attachment 287859 [details]).

So I guess the only question here would be whether we prefer FF2 behavior (text not wrapped) or Trunk behavior (text wrapped).

As described in comment 12, trunk behavior matches dbaron's proposed table-layout spec, so we should probably stick with that, even if breaks some webpages.

dbaron, should we WONTFIX this bug?

Comment 16

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

I think it makes more sense to honor what the author says when it's possible and reasonable to do so, so yes, I think WONTFIX.

Comment 17

[Daniel Holbert [:dholbert]]

Resolving as WONTFIX, per comments 15 and 16.