130492 - {inc} Table reflow sometimes fails, resulting overlapping cells [colgroup + rowspan]

Status: RESOLVED FIXED

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

Description

[Igor Furlan]

Click on this link and wonder what mozilla does with a table.

Before you click on the link, please check the attachment wich I will
upload after "Commit"

You will see two browsers MSIE 5.5 and mozilla 0.9.9

MSIE does a perfect job... mozilla is lost

ADDITIONAL NOTE:
you can confuse mozilla very easily by scrolling the page BEFORE the complete
download and rendering is done

my system 
Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.9) Gecko/20020310 (REDHAT6.2)

Comment 1

[Igor Furlan]

Attachment: MSIE5.5 and moz0.9.9 table rendering comparison

It does not happen always...but very often... it seems that the table
is simply too big and too complicated	mozilla has a better chance to render
the table correctly if you do not touch it during the  task...I mean..	no
scrolling  no e-mail writting and sending ...

Comment 2

[Andrew Schultz]

worksforme with Linux build 20020309.  this actually looks like a dupe of bug
118532 (see the screenshot there), which was marked WORKSFORME...

Comment 3

[Doron Rosenberg (IBM)]

wfm win 0.9.9 on win98

Comment 4

[uamjet602]

Confirmed linux 2002031822

I think wether you see this depends on your network connection. The table is
reflowed a lot of times while the page loads. Sometimes it is reflowed
correctly, sometimes it is not. Also when I reload the problem goes away.

Comment 5

[David Chester]

I cannot reproduce this in 1.0rc1. Reporter Igor Furlan,
please can you check to see whether this bug is still present in a recent build
(Moz1-RC1 or a new nightly build). If this bug does not occur please can you
resolve it worksforme. For further information on bug writing please see
http://www.mozilla.org/quality/bug-writing-guidelines.html

Comment 6

[Boris Zbarsky [:bzbarsky]]

to HTMLTables component.  A testcase would be nice here.  :)

Comment 7

[Igor Furlan]

Attachment: release candidate 1 is not better than previous releases

This URL http://www.bath.ac.uk/%7Epy8ieh/cgi/listresults.pl?ID=ETS
is still a problem for mozilla 1.0RC1

Comment 8

[Igor Furlan]

same problem with RC2  

Comment 9

[Henri Sivonen (:hsivonen)]

WFM with RC2 on OS X.

Comment 10

[Igor Furlan]

RC3 on LINUX:  still the same problem

Comment 11

[Kari Hurtta]

Table looks strange also on Mozilla 1.0.0+ , Build ID 2002060221, Linux

Comment 12

[Andrew Schultz]

Attachment: the elusive testcase

linux trunk build 20020615
note that the rowspans do not work (replacing each with 2 cells makes the bug
go away)
removing the class or title specifications on the <COL> elements also makes the
testcase render properly.

Comment 13

[Igor Furlan]

not yet solved in

Mozilla 1.1a
Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.1a) Gecko/20020610

Comment 14

[Igor Furlan]

not solved yet
Mozilla 1.1b
Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.1b) Gecko/20020722

Comment 15

[Daniel Wang]

Attachment: screencapture of testcase

The problem still exists on Mozilla 2003031408/win98 (you will need to
revisit the page a few times to see it happen)

I could not come up with a simpler reduced testcase. But I can confirm that
removing the colgroup code also removes the bug (comment 12).
I note that the # of cols defined in colgroup is 2 less than the
actual # of cols (could that be a problem?)

When I load the page, sometimes I see the wrong layout briefly, but
the table quickly reflows correctly, so perhaps Mozilla sometimes
fails to call the last reflow?

(Note the right end of the screencapture. Cells are truncated)

Comment 16

[Andrew Schultz]

reassign

Comment 17

[Boris Zbarsky [:bzbarsky]]

Daniel, Andrew, I can't seem to reproduce the problem with that testcase... are
you still seeing it?

Comment 18

[Daniel Wang]

yes. I had to reload the testcase 4 or 5 times to get the broken result. Mozilla
1.5/win2k

Comment 19

[Andrew Schultz]

Attachment: simpler testcase

this testcase is 100% reproducible.  it uses javascript-forced reflow rather
than just being too large to do in one chunk.

Comment 20

[Bernd]

this has been fixed by the patch in bug 248474