145111 - Nested shrink-to-fit does not use the available width

Status: RESOLVED FIXED

(Core :: Layout: Positioned, defect)

Description

[Eric Krock]

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.

Comment 1

[Andrew Hagen]

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

Comment 2

[Eric Krock]

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.

Comment 3

[Daniel Wang]

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

Comment 4

[karnaze (gone)]

mass reassign to default owner

Comment 5

[Barry Platt]

Attachment: Testcase #1 (TABLE)

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.

Comment 6

[Barry Platt]

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.  

Comment 7

[John Simons]

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

Comment 8

[Eric Krock]

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.

Comment 9

[Martijn Wargers (dead)]

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.

Comment 10

[Bernd]

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

Comment 11

[Mats Palmgren (inactive)]

(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.

Comment 12

[Mats Palmgren (inactive)]

Attachment: Testcase #2 (DIV)

Comment 13

[Mats Palmgren (inactive)]

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)