86249 - Border of a very long table breaks (overflow?)

Status: RESOLVED FIXED

(Core Graveyard :: GFX, defect)

Description

[Robert Kroiß]

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.

Comment 1

[Henri Sivonen (:hsivonen)]

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.

Comment 2

[Andriy Palamarchuk]

Attachment: Test case

Comment 3

[Andriy Palamarchuk]

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.

Comment 4

[rubydoo123]

triaging: table bug

Comment 5

[Christopher Hoess (gone)]

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

[anthonyd]

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

Comment 7

[karnaze (gone)]

Temporarily moving to future until a milestone can be assigned. 

Comment 8

[Jim Smart]

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

[Jim Smart]

Attachment: better test case

Comment 10

[Jim Smart]

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

[Jim Smart]

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

[Jim Smart]

Attachment: showing messed up border on DIV taller than 33k pixels

Comment 13

[Jim Smart]

Attachment: showing different manifestation of DIV border problem (taller than 65k pixels)

Comment 14

[Horst Gutmann]

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

[Jim Smart]

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

[Jim Smart]

actually, after a quick sanity check, all of the test cases have borders that
look ok to me using the above mentioned build.

Comment 17

[Mats Palmgren (inactive)]

*** Bug 138296 has been marked as a duplicate of this bug. ***

Comment 18

[Mats Palmgren (inactive)]

--> GFX Compositor

Comment 19

[Tuukka Tolvanen (sp3000)]

*** Bug 173905 has been marked as a duplicate of this bug. ***

Comment 20

[Kevin McCluskey (gone)]

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

Is this still a problem on Linux?

Comment 21

[Artur Polaczynski]

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

[Bernd]

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

[Bernd]

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 24

[Bernd]

Attachment: patch

Comment 25

[Bernd]

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.

Comment 26

[Bernd]

*** Bug 113069 has been marked as a duplicate of this bug. ***

Comment 27

[Robert O'Callahan (:roc) (email my personal email if necessary)]

Comment on attachment 116118 [details] [diff] [review]
patch

Looks good to me and the logic is simple enough. Check it in.

Comment 28

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

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).

Comment 29

[Robert O'Callahan (:roc) (email my personal email if necessary)]

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

[Bernd]

fix checked in - no performance gain at tinderbox