Border of a very long table breaks (overflow?)

RESOLVED FIXED in Future

Status

RESOLVED FIXED
18 years ago
10 years ago

People

(Reporter: e9725486, Assigned: kmcclusk)

Tracking

({testcase})

Trunk
Future
x86
Linux
testcase

Firefox Tracking Flags

(Not tracked)

Details

(Whiteboard: [bae:table], URL)

Attachments

(5 attachments)

(Reporter)

Description

18 years ago
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?)

Comment 2

18 years ago
Created attachment 41578 [details]
Test case

Comment 3

18 years ago
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.
Keywords: testcase

Comment 4

17 years ago
triaging: table bug
Whiteboard: [bae:table]
Current behavior: the page initially lays out correctly, but scrolling down and
then back up damages the upper right corner of the table.

Comment 6

17 years ago
I'm not seeing this at all, it seems to work fine for me.

Comment 7

17 years ago
Temporarily moving to future until a milestone can be assigned. 
Status: NEW → ASSIGNED
Target Milestone: --- → Future

Comment 8

17 years ago
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 ?

Comment 9

17 years ago
Created attachment 88047 [details]
better test case

Comment 10

17 years ago
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 ?

Comment 11

17 years ago
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.

Comment 12

17 years ago
Created attachment 88056 [details]
showing messed up border on DIV taller than 33k pixels

Comment 13

17 years ago
Created attachment 88057 [details]
showing different manifestation of DIV border problem (taller than 65k pixels)

Comment 14

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

Comment 15

17 years ago
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]

Comment 16

17 years ago
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. ***
(Assignee)

Comment 20

16 years ago
WFM: Using 10/16/2002 cvs trunk build on WinXP.

Is this still a problem on Linux?

Comment 21

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

Comment 22

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

Comment 23

16 years ago
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.

Comment 25

16 years ago
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.

Updated

16 years ago
Attachment #116118 - Flags: review?(roc+moz)

Comment 26

16 years ago
*** 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.
Attachment #116118 - Flags: superreview+
Attachment #116118 - Flags: review?(roc+moz)
Attachment #116118 - Flags: review+
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.

Comment 30

16 years ago
fix checked in - no performance gain at tinderbox
Status: NEW → RESOLVED
Last Resolved: 16 years ago
Resolution: --- → FIXED
Product: Core → Core Graveyard
You need to log in before you can comment on or make changes to this bug.