Using Mozilla RC2 on WinXP Pro. There is a very infrequent bug in which an HTML table will initially lay out in such a way that the cells do not line up in columns as expected. Shift-reload causes the page to lay out correctly. The document on which I see this bug is an HTML page that was output from Microsoft Excel. Unfortunately I can't attach the document to this public bug report because it is our internal employee phone book. I just saw this today using Mozilla RC2 on WinXP Pro, but I recall seeing the same problem a long time ago in earlier Mozilla builds running on WinME. At that time I thought it was an artifact of running low on memory due to having many windows open, but today it occurred with only five Mozilla, 3 Excel, and 1 AIM window open on a Dell Latitude C600 with 256M of RAM. This is a very, very infrequent problem, however it's real. Marking Severity minor and not nominating for a milestone at this time. Next time I see this I'll remember to take a screen shot and then edit it to remove the company confidential information. In the meantime, imagine a table in which each cell takes up as much horizontal space as it needs to hold its own contents, but not more, with no cross-row coordination of the cells into columns as expected. Therefore every row lays out its cells independently. This creates a table that's unreadable and unusable for practical purposes.

Reporter, does Reload cause this problem to occur? Have you found a testcase?

FYI: Saw this again on the same confidential phone book doc in Moz 1.3b. Didn't think to capture screen shot. Will try to create nonconfidential test case if time allows.

Reporter, does the problem occur if you load the file locally? and can you produce a testcase?

mass reassign to default owner

The table cells in this document do not align vertically in Mozilla Firebird 0.7 and Mozilla Suite 1.4, or in Mozilla Composer 1.4.

Further to my earlier comment, the issue seems to be related to the 'position: absolute' in .main-outer and .main. If one of these is removed, the columns are aligned correctly.

This is the currently the only major bug I notice in everyday use. On several pages I find that a table layout renders incorrectly until the page is reloaded. Examples include: http://success.shoreline.edu/ebbtide/archive/v39/11/ - Table cell overflows http://www.royalbarrel.com/portfolio.php - Thumbnails should run in two columns

Just confirming I'm still seeing this on XP SP1 with Moz 1.7 [Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7) Gecko/20040514] using same darn internal phonbook doc created by Excel.

I think this is already fixed somehow. I can't see the bug with the testcase, using: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8a6) Gecko/20050103 Firefox/1.0+ I can see the bug, using Mozilla1.4 (and Mozilla1.7), though. The rendering has changed even more with this testcase, it is now rendering the same as Opera7.53, which - I think - is correct.

Mats, didn't you fix this in bug 201897 ?

(In reply to comment #10) > Mats, didn't you fix this in bug 201897 ? Partly, the cells now line up correctly and there is no incr. reflow problem. The remaining issue is the width. The problem, I think, is that the "available width" is not passed down correctly in a nested shrink-to-fit situation (the testcase works correctly if you remove the "main-outer" DIV). The remaining issue is not a table problem per se.

Actually, I think the current rendering is correct and that I was wrong in comment 11. There is nothing in CSS 2.1 AFAICT that says available width should be "inherited" like that. http://www.w3.org/TR/CSS21/visudet.html#abs-non-replaced-width The containing block is "main-outer" and it has width:0, thus the inner abs.pos. block "main" will be sized to its minimum width. -> FIXED (by bug 201897)