Closed Bug 324955 Opened 15 years ago Closed 14 years ago

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


(Core :: Layout: Tables, defect)

Not set





(Reporter: uriber, Unassigned)




(Keywords: rtl, testcase, Whiteboard: [reflow-refactor])


(2 files)

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, originally reported by arik487 on the Firefox forum.

Testcase coming up.
Attached file testcase
The outer (red) table should expand to surround the inner (blue) table. This happens for LTR but not for RTL.
Keywords: testcase
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.
There is no need to second guess whats going on here, just run a reflow log...
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 
Thanks, Brend.

The bugus left margin originates from
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?
>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. 
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).
Whiteboard: [reflow-refactor]
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
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
Closed: 14 years ago
Depends on: reflow-refactor
Resolution: --- → FIXED
Need regression test.
Flags: in-testsuite?
Mass-assigning the new rtl keyword to RTL-related (see bug 349193).
Keywords: rtl
You need to log in before you can comment on or make changes to this bug.