324955 - In an RTL table, a TD with specified width does not expand to contain a nested table with a larger specified width

Status: RESOLVED FIXED

(Core :: Layout: Tables, defect)

Description

[Uri Bernstein]

In an RTL table, if a table cell (TD) with a width="n" attribute contains a table with width="m", and m>n, the cell does not expand to surround the nested table, but remains in its specified width (n).

This is the root cause of the rendering problem in http://www.hondaclub-il.net/, originally reported by arik487 on the mozilla.co.il Firefox forum.

Testcase coming up.

Comment 1

[Uri Bernstein]

Attachment: testcase

The outer (red) table should expand to surround the inner (blue) table. This happens for LTR but not for RTL.

Comment 2

[Uri Bernstein]

Interestingly, repeated reflows (caused e.g. by changing the text size back and forth), causes the outer table to gradually grow until it reaches the correct width.

Comment 3

[Bernd]

There is no need to second guess whats going on here, just run a reflow log...
http://www.mozilla.org/newlayout/doc/frame_reflow_debug.html

Comment 4

[Bernd]

the inner table gets a negative left margin computed and as consequence the outer table reports a bogus size.

 tblO 033A7CC8 r=0 a=UC,UC c=UC,UC cnt=149
  tbl 033A7DC4 r=0 a=UC,UC c=2445,UC cnt=150
   rowG 033A755C r=0 a=UC,UC c=UC,UC cnt=151
    row 033A7F84 r=0 a=UC,UC c=UC,UC cnt=152
     cell 033A81F4 r=0 a=UC,UC c=UC,UC cnt=153
      block 033A8254 r=0 a=UC,UC c=UC,UC cnt=154
       text 033A8348 r=0 a=UC,UC c=UC,UC cnt=155
       text 033A8348 d=1425,285 me=795
      block 033A8254 d=1425,300 me=795
     cell 033A81F4 d=1485,360 me=855
    row 033A7F84 d=UC,360
   rowG 033A755C d=UC,360
   colG 033A7744 r=0 a=UC,UC c=UC,UC cnt=156
    col 033A53E4 r=0 a=0,0 c=-30,UC cnt=157
    col 033A53E4 d=0,0
   colG 033A7744 d=0,0
  tbl 033A7DC4 d=2475,450 me=2475
 tblO 033A7CC8 d=45,450 me=45 o=(-2430,0) 2475 x 450 

Comment 5

[Uri Bernstein]

Thanks, Brend.

The bugus left margin originates from http://bonsai.mozilla.org/cvsblame.cgi?file=mozilla/layout/generic/nsHTMLReflowState.cpp&rev=1.233#2137
This code (availMarginSpace < 0) was originally introduced for bug 6155. The table case specifically was discussed much in bug 185411 comment #16 and onwards.

Removing the |if (mStyleVisibility->mDirection == NS_STYLE_DIRECTION_RTL)| case fixes the symptoms of this bug, but causes RTL tables to overflow to the right when the viewport is too narrow to contain them. I'm not sure if that's really wrong (Safari does the same), and in any event we have more "content overflows to the right when it should overflow to the left in RTL blocks" issues (see bug 318116) - so maybe the fix should really be somewhere else.

Perhaps someone who really understands the code can comment?

Comment 6

[Bernd]

>who really understands the code can comment

This should exclude me from commenting, but what I know for sure is that the table margin handling is a blatant hack (see bug 260980 comment 9). I have to admit that I took part in this. 

Comment 7

[Uri Bernstein]

Attachment: LTR testcase with margins

This is an LTR-only testcase, demonstrating a related issue when a left or right margin is set on an inner table inside a cell with a specified small width. cases 2 and 4 should look like 1 and 3 respectively, and a single forced reflow (using ctrl-+) indeed causes them to look that way.

See also bug 164457, which is similar (but not identical, as far as I can tell).

Comment 8

[Peter van der Woude [:Peter6]]

Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.9a1) Gecko/20061208 Minefield/3.0a1 ID:2006120812 [cairo]

seems fixed after reflow branch landing

Comment 9

[Uri Bernstein]

Indeed, fixed by the reflow branch landing.
Verified with:
Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.9a1) Gecko/20061208 Minefield/3.0a1 ID:2006120806

Comment 10

[Boris Zbarsky [:bzbarsky]]

Need regression test.

Comment 11

[(no longer active)]

Mass-assigning the new rtl keyword to RTL-related (see bug 349193).