318704 - Only part of table border rendered, stochastic what triggers the problem

Status: NEW

(Core :: Layout: Tables, defect)

Description

[John Olsson]

User-Agent:       Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8) Gecko/20051111 Firefox/1.5
Build Identifier: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8) Gecko/20051111 Firefox/1.5

I maintain an internal web page containing two tables. The layout for the two tables is controlled via an embedded CSS in the HTML file. Sometimes (this has occurred for both Mozilla and Firefox for Mozilla versions 1.3 to 1.7 and for Firefox from 1.0 to 1.5) the tables are not rendered correctly. What happens is that the borders for the 2nd table is only rendered for the bottom half of the table and the rest of the table is without any borders.

If I change/add/remove a couple of characters in the HTML file the 2nd table magically renders correctly and when I revert the changes I made the problem occurrs again. I have not been able to find out what actually triggers the problem, since there is no consistency in what I need to change in order to get the page rendered correctly. sometimes it is a link that I need to truncate and sometimes it is plain text added to a cell that I need to change in order to get the page rendered correctly.

Thus I will add two attachments to this bug report, one HTML file that renders correctly and one that does not render correctly. The only difference between them is that I have truncated the link for the "December 05, 2005" entry, that is the link was changed from "http://ccnd.ericsson.se/prodsupport/axe/sts/pc-sts/reviews/113/218-159_41-FCPW_101_97-F_Uen_PA24.pdf" to "http://ccnd.ericsson.se/prodsupport/axe/sts/pc-sts/reviews/113/218-159_41-FCPW_101_97-F_Uen_P".


Reproducible: Always

Steps to Reproduce:
Once an HTML file causes the borders for a table to not render correctly it will happen every time. What is stachastic is when the problem occurrs, i.e. I can not predict what I need to modify in an existing HTML file to provoke the problem. I can not create a simple test case, it is simply something that comes and goes as I add more to the HTML table.
Actual Results:  
Only the borders for a part of a table is rendered, the other part does not get any borders at all.

Expected Results:  
The table should be rendered correctly. :)

Comment 1

[John Olsson]

Attachment: File rendered correctly

Comment 2

[John Olsson]

Attachment: File does not render correctly

The only change between this file and the one that renders correctly is that the link for "December 05, 2005" to the document is truncated ("A24.pdf" removed from the end of the URL).

Comment 3

[Andrew Schultz]

I'm seeing a problem with a 1.8 branch build, but not trunk (2005-12-02).  Can you test a trunk build?

http://ftp.mozilla.org/pub/mozilla.org/firefox/nightly/latest-trunk/

Comment 4

[Bernd]

John the issue is the border-collapse:collapse. A workaround is to specify the cellspacing="0" and work with border-collapse:separate. Its a known bug.

Comment 5

[Bernd]

this is very probably a dupe of bug 244135

Comment 6

[John Olsson]

I have now switched from using border-collapse:collapse to border-collapse:separate and it does *not* trigger the rendering bug. :)

I have also tried with Deer Park 2 (firefox-1.6a1.en-US.linux-i686.tar.bz2) and it still shows some strange behaviour. For instance my attachment "File rendered correctly" does not really render correctly. When loading the attachment I can see the borders applied correctly and then they disappear. A reload of the page partly fixes the problem, but the vertical borders just shows up and then disappears.

The attachment labeled "File does not render correctly" renders *better*. When loaded the horizontal border are applied correctly and a reload makes the vertical borders appear as well...

From the description of bug 244135 it seams to be the same. One comment for that bug states that it is enough to have both border-collapse:collapse and rowspan=4 to trigger the bug, but this is not the case. My examples contains three cells with rowspan=4, but this is not enough to trigger the bug. Random changes to the text contents of cells or links can trigger or untrigger the bug.

Comment 7

[Steve England [:stevee]]

Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.9a9pre) Gecko/2007101504 Minefield/3.0a9pre ID:2007101504 (post bug 244135)

For me _both_ testcases presented here sometimes show the problem where by the table borders aren't drawn for roughly the first half of the table.

I also sometimes see this phenomena with attachment 201169 [details] (a testcase from bug 244135). Most of the time when I load this testcase all borders are visible when the page has finished loading, but occasionally the top part of the table is borderless. Two screenshots to follow.

Comment 8

[Steve England [:stevee]]

Attachment: From attachment 201169 - note no borders are visible

Comment 9

[Steve England [:stevee]]

Attachment: From attachment 201169 - note borders suddenly appear

Comment 10

[Steve England [:stevee]]

Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.9a9pre) Gecko/2007101405 Minefield/3.0a9pre (pre bug 244135)

FWIW I just tested the two testcases attached to this bug with a build that was before the landing of bug 244135, and I can still get them both to misrender in the same way as I can with a build that includes bug 244135.

So with respect to comment 5, I do not think this is a dupe of bug 244135.

Comment 11

[fantasai]

Malcolm's latest patch to bug 244135 (just landed) seems to have fixed this.

Comment 12

[fantasai]

Nevermind. It's still broken. :(

Comment 13

[Michael Dayah]

This is an exceptionally ugly bug when using thick, border-collapsed borders. Is there a consistent way to detect if it's been triggered using getComputedStyle or otherwise so a reload can be triggered to fix it?

Comment 14

[Michael Dayah]

Attachment: Screenshot of bug not triggered

Comment 15

[Michael Dayah]

Attachment: Screenshot of bug triggered

I'm adding these screenshots because this example uses very thick borders with table cell background colors and background images. It's much clearer exactly what's involved. Background colors from nearby cells bleed into the bordered region, but images do not, as seen with the gradients hovering neatly inside their boundaries. Also, notice the bleeding in eventually stops and doesn't affect the Lanthanoids and Actinoids.

Comment 16

[Malcolm Parsons]

I haven't found time to work on this.