260049 - {incr} cell width information not honoured if in new attached row.

Status: RESOLVED FIXED

(Core :: Layout: Tables, defect)

Description

[Volker Moell]

User-Agent:       Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8a4) Gecko/20040910 Mnenhy/0.6.0.104
Build Identifier: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8a4) Gecko/20040910 Mnenhy/0.6.0.104

On page http://die-moells.de/volker/tests/small_table.html are 144 tables,
generated with the same CGI code from
http://die-moells.de/volker/tests/small_table.cgi_ (the "_" is important for
download reason!).  

Some of the tables did not have the claimed fixed width of 600, they are only as
wide as needed. It's not predictable, *which* tables are formatted incorrectly,
but mostly there are some of them defective.

Reproducible: Sometimes
Steps to Reproduce:
1.Open http://die-moells.de/volker/tests/small_table.html

Actual Results:  
Some tables are too short

Expected Results:  
All tables should have width 600 as claimed in the code

On http://die-moells.de/volker/tests/small_table.jpg you see a screenshot as a
proof: Here tables 0009 and 0015 have this problem.

I tried to simplify the CGI script generated the testing URL without much
success. So sorry that my demo page is so large...

Comment 1

[Volker Moell]

Attachment: Screenshot as proof

Comment 2

[Volker Moell]

Attachment: Perl-CGI script which creates demo page

Comment 3

[Ruediger Lahl]

Bug is also in msvc-nightly. Testet with Mozilla/5.0 (Windows; U; Windows NT
5.1; en-US; rv:1.8a4) Gecko/20040917(02)

Comment 4

[Volker Moell]

See Message-ID <[e-mail]> from Sven Grull in
de.comm.software.mozilla.nightly-builds:

Sven can confirm the bug under XP with the latest nightly.

And he changed the page, because it was not valid. the bug is still there.
http://grull.com/mozilla/small_table.html

The site in XHTML, so that it's rendered in Standard Compliance Mode, but
unfortunately not valid. But in this rendering mode the bug still is present:
http://grull.com/mozilla/small_table_x.html

Comment 5

[Sven Grull]

I have added a vaild xhtml page:
http://grull.com/mozilla/small_table_x_v.html
For this page the bug is also present.

Comment 6

[Bernd]

We need a really reduced testcase, I guess this is a incr. reflow bug, one needs
to place layout-break points around/inside the table frames to make this
reproducible ( see http://www.mozilla.org/newlayout/doc/fosdem2004/slide19.html
and ff for a more detailed description how this can be done.)

Comment 7

[Erik Fabert]

Attachment: New testcase

The <script> has to be between two table rows to trigger this bug.

Comment 8

[Volker Moell]

Attachment: Original testcase

It seems that I didn't attached the original testcase.	Here is it.
But there were no "<script>" tags in it.

Comment 9

[Volker Moell]

Attachment: Perl-CGI script which creates demo page (10 tables only)

Quite interesting: 

* If I chance in the GCI script from attachment #159200 [details] the number of tables
from 150 to 10 and run this CGI script via apache2, table 9 in the majority of
Ctrl-Shift-R[eloads] is shortened.

* But when I "save as" exactly this output as an HTML page (or even "wget" it)
I could not reproduce this bug at all: I tried it at least 50 times to
Shift-Ctrl-R[eload] without any table being shortened.

Is there any difference in layouting when viewing CGI vs. HTML pages?

Comment 10

[Bernd]

Eriks testcase is exactly what I was looking for. Thanks a lot.
The issue here is that during incr. reflow the width information of the cell is
not honored it should. The CGI probably does not generate the HTML as fast as
serving the page as HTML directly this causes incr. reflows. The mechanism is
described in the link to the fosdem talk.

Comment 11

[Martijn Wargers (dead)]

This got fixed on trunk between 2006-12-07 and 2006-12-08, so fixed by the reflow branch landing.
I added a reftest in bug 271747, I think it basically covers also this testcase (I think this bug and that bug are basically the same).