116.63 KB, text/html
121.22 KB, text/html
374 bytes, text/html
380 bytes, text/html
1.57 KB, patch
|Details | Diff | Splinter Review|
When viewing this page (long table, search result), the border of the table is rendered like this: | | | | -------------------- Table content ... -------------------- | | | | Looks like a overflow problem. It does not happen when the same layout is used with a shorter table. I can produce this bug in Mozilla 0.9.1 and Mozilla 0.8 under Linux. I havent tried it using Mozilla WIN, but Netscape 6.01 does not show this bug. This html-File is qualified as valid HTML 4.01 Transitional by the W3C validator.
The doctype of the test case triggers the Quirks mode. However, the problem also occurs in the standards mode. Confirmed. The border of the table doesn't go all the way around the table.
Status: UNCONFIRMED → NEW
Ever confirmed: true
Summary: table border drawn wrong (overflow ?) → Border of a very long table breaks (overflow?)
I have the same problem on Mozilla 0.9.2 (build 2001062823), Linux (see the attachment above). When I remove one more row from the table the bug does not show. Sometimes the borders are rendered correctly the first time you load the page, try to go page-up/down. When the documents was bigger the bug was reproducable each time. The attached document is validated in w3 online validor against XHTML 1.0 strict.
triaging: table bug
Current behavior: the page initially lays out correctly, but scrolling down and then back up damages the upper right corner of the table.
I'm not seeing this at all, it seems to work fine for me.
Temporarily moving to future until a milestone can be assigned.
Status: NEW → ASSIGNED
Target Milestone: --- → Future
I am seeing this consistently with Mozilla 1.0 2002061606 and Mozilla 1.1 Alpha builds, under Win32. I /can/ see this bug on the existing test case, but it is not as obvious as it can get in the realworld (my web pages are obviously just too long!). I've improved the existing test by (a) ensuring the main table has been shifted away from the top and bottom of the page, (b) ensuring the main table has a small width, thus ensuring it will alway be too long, and (c) I've increased the borders of the main table from 1 to 3 making the whole effect much more obvious. Is this the same as, or related to, bug #102309 ?
Oh, perhaps I should say that that I am only able to test currently on Windows ME - my Win2k box is dead. Is this bug also related to, or the same as bug #113069 ?
I also see border problems with really tall DIVs too. I think this is an issue connected with 16bit signed/unsigned precision, as the DIV is ok if smaller than ~33k pixels in height, and is messed up in a different way when bigger than ~66k pixels in height. I'll attach two more test cases showing this behaviour.
Created attachment 88057 [details] showing different manifestation of DIV border problem (taller than 65k pixels)
see this problem with dynamic changed background-color for a cell. but only the left side is affected http://www.edu.uni-klu.ac.at/~hgutmann/go-forever/forum/index.php <-test case
this is duplicated in bugs #138296 and #113069 Horst: your testcase works for me [Windows 2000: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.1) Gecko/20020812]
actually, after a quick sanity check, all of the test cases have borders that look ok to me using the above mentioned build.
*** Bug 138296 has been marked as a duplicate of this bug. ***
--> GFX Compositor
Assignee: karnaze → kmcclusk
Status: ASSIGNED → NEW
Component: HTMLTables → GFX Compositor
QA Contact: amar → petersen
*** Bug 173905 has been marked as a duplicate of this bug. ***
WFM: Using 10/16/2002 cvs trunk build on WinXP. Is this still a problem on Linux?
Build 2003011522 / linux table is broken if have 32760px or more height (32770 is small than 2^15 btw) i check mozilla v 1.0.1/win32 too and the same problem
void nsCSSRendering::FillPolygon obviously feeds values like 37068 into the drawing routines. MS at least under win98 is not very happy about it. http://msdn.microsoft.com/library/default.asp?url=/library/en-us/win9x/chilimit_0ap1.asp
http://lxr.mozilla.org/seamonkey/source/layout/html/style/src/nsCSSRendering.cpp#1667 describes what needs to be done, border painting code should honour the dirtyRect.
David and Robert, I need some guidance how to test the patch, it fixes the bug and I scrolled through the testcases at layout/html/tests/table/printing. Thanks for your help.
*** Bug 113069 has been marked as a duplicate of this bug. ***
Comment on attachment 116118 [details] [diff] [review] patch Looks good to me and the logic is simple enough. Check it in.
Yeah, looks good to me too, although in a sense this is a workaround for a bug in the platform GFX code that's somewhat hard to fix (see bug 115526).
That's true, but doing it here too will improve perf a little bit so I think it's worth having on its own.
fix checked in - no performance gain at tinderbox
Status: NEW → RESOLVED
Last Resolved: 16 years ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.