145405 - Excess vertical space given to 'rowspan synthesized' table cell

Status: NEW

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

Description

[John Morrison]

Overview Description: 

I noticed this on the nytimes.com website. There is a greater amount of 
vertical whitespace in the layout of the pages for some articles (see
attached screenshot).

I reduced it down to this pattern, where they over-specify a rowspan. 
In mozilla, as in other browsers, we "synthesize" a row. But in mozilla
we seem to allocate an equal share of the vertical space even though 
it has no content within the cell. (Hope that makes sense; hands waving).

Steps to Reproduce: 
1) view the attached testcase

Build Date & Platform Bug Found: 
  seen in win2k 05-12-1.0.0 commercial build, and in a trunk build
  pulled from cvs last night.

  For the original URL, each time I reload the page, there seems to be 
  a different amount of whitespace assigned. But, at any rate, ideally
  there should be none assigned.


HTML is

<table border="1" width="300">
  <tr>
    <td rowspan="2">
      x<br>x<br>x<br>x<br>x<br>x<br>x<br>x<br>
    </td>
    <!-- this second 'rowspan' causes a different layout -->
    <td rowspan="2">
      x<br>x<br>x<br>x<br>x<br>x<br>x<br>x<br>
    </td>
  </tr>
  <tr>
    <td valign="top">
      article goes here; note the greater amount of space given
      to the synthesized row above when viewed in mozilla, as 
      opposed to nav4.x or ie
    </td>
  </tr>
</table>

Comment 1

[John Morrison]

Attachment: screenshot of the affected page.

Comment 2

[John Morrison]

Attachment: simple testcase with two rowspan=2 in first row, and then a single td in the second row

Comment 3

[Amarendra Hanumanula]

adding testcase keyword

Comment 4

[John Morrison]

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

Comment 5

[Boris Zbarsky [:bzbarsky]]

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

Comment 6

[Sam J. Fleet]

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

Comment 7

[Sam J. Fleet]

I have enclosed two testcases to bug #164270.  Feel free to use this for 
continuing testing.  On 2nd thought, I'll add it here for your convience.

Testcase #1 showed the bug.  This exactly mirror the problem we saw at that 
website, "http://www.fortune.com/lists/G500/losers.html".  Testcase #2 showed 
what the bug would look like if excessive data aren't in either table #5 or 
table #6.  (In the testcase).

Comment 8

[Sam J. Fleet]

Attachment: Dup bug #164270, testcase #1

Comment 9

[Sam J. Fleet]

Attachment: Dup bug #164270, testcase #2

Comment 10

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

FWIW, I had made a simplified testcase for this problem once, and found it to be
very sensitive to a width on something --- the 4.x behavior only occurred when
the widths were set up in a certain way.  That made me decide not to file the
bug, and I'm not sure exactly what the issue was...

Comment 11

[Hyman Rosen]

I know I'm griping, and that if I want something fixed I should
do it myself, and so forth, but you would think that a layout bug
of this prominence would get a little attention. It makes reading
the AP news stories on the NYTimes web site incredibly annoying.

Comment 12

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

It's really not even a bug, and is only an issue because the site is poorly
designed and depending on the way certain browsers happen to lay out this markup.

Comment 13

[Hyman Rosen]

Once the page has finished loading and displays incorrectly,
the slightest resize makes it display properly. If that isn't
a bug, then I don't know what is. Not only that, when starting
to load, the page looks like it will load properly, with
pieces showing up in the right spots, then everything abruptly
moves to the wrong position. It's just plain broken.

Comment 14

[John Morrison]

Seriously, this is not blocking 1.4a.

Look. I reported the bug, I have a ton of experience of poking around with 
table layout bugs, I read the Times almost daily, and I don't view this as 
all that serious a problem. It might be nice to go with the precedent, but
it's not a priority. What a user agent should do with that testcase is 
completely undefined.

Comment 15

[karnaze (gone)]

mass reassign to default owner

Comment 16

[Wayne Mery (:wsmwk)]

(In reply to comment #14)
> What a user agent should do with that testcase is completely undefined.

In that case, should this be fixed?

Comment 17

[Mats Palmgren (inactive)]

The reflow branch landing seems to have fixed one of the problems.
In the "Dup bug #164270..." testcases, the last (tall) cell in the 2nd row
that contains "**" is now only wide enough to fit the text (using a 
SeaMonkey 2006120801 build on Linux). In 2006120701 this cell is wider.
The new rendering of this cell is the same rendering as in IE7, Opera9 and
roughly the same as in a recent Webkit.

The remaining problem, described the summary, is best illustrated by the
first testcase. IE7, Opera9 and Webkit have the same layout for that testcase.

Comment 18

[Bernd]

Attachment: reference rendering for testcase #2

Comment 19

[Tal Aloni]

Like David said, This is not a bug and should be closed, the HTML specs do not mandate cells to be stretched over empty cells like the OP expects.

p.s.
I believe that this is the area in the code that is responsible (and the calculations above it):
http://mxr.mozilla.org/mozilla-central/source/layout/tables/nsTableRowGroupFrame.cpp?mark=682-702#682

Comment 20

[BugBot [:suhaib / :marco/ :calixte]]

The severity field for this bug is relatively low, S3. However, the bug has 3 duplicates.
:dholbert, could you consider increasing the bug severity?

For more information, please visit auto_nag documentation.

Comment 21

[BugBot (nomail) [:suhaib / :marco/ :calixte]]

The last needinfo from me was triggered in error by recent activity on the bug. I'm clearing the needinfo since this is a very old bug and I don't know if it's still relevant.