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




Layout: Tables
14 years ago
11 years ago


(Reporter: Volker Moell, Unassigned)


Dependency tree / graph
Bug Flags:
in-testsuite -

Firefox Tracking Flags

(Not tracked)




(5 attachments)



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

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

14 years ago
Created attachment 159199 [details]
Screenshot as proof

Comment 2

14 years ago
Created attachment 159200 [details]
Perl-CGI script which creates demo page


14 years ago
Attachment #159200 - Attachment description: CGI script which creates demo page → Perl-CGI script which creates demo page
Attachment #159200 - Attachment mime type: text/tab-separated-values → text/plain

Comment 3

14 years ago
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

14 years ago
See Message-ID <414B1722.6030908@grull.com> from Sven Grull in

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.

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:

Comment 5

14 years ago
I have added a vaild xhtml page:
For this page the bug is also present.

Comment 6

14 years ago
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.)
Keywords: qawanted

Comment 7

14 years ago
Created attachment 160717 [details]
New testcase

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

Comment 8

14 years ago
Created attachment 160718 [details]
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

14 years ago
Created attachment 160724 [details]
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

14 years ago
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.
Ever confirmed: true
Keywords: qawanted
Summary: Tables with fixed width are not rendered correctly sometimes (width is ignored) → {incr} cell width information not honoured if in new attached row.


14 years ago
Blocks: 271747
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).
Last Resolved: 11 years ago
Depends on: 300030
Flags: in-testsuite-
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.