398980 - [BC] table borders in a collapsed table randomly missing

Status: RESOLVED WORKSFORME

(Core :: Layout: Tables, defect)

Description

[Rasmus Schultz]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.1.7) Gecko/20070914 Firefox/2.0.0.7
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.1.7) Gecko/20070914 Firefox/2.0.0.7

On the page referred above, some random table borders will be missing every time you reload the page.

Reproducible: Sometimes

Steps to Reproduce:
1. load the page referred above
2. scroll down
3. most of the time, some borders will be missing - if not, reload the page
Actual Results:  
some table borders go missing - apparently, which ones go missing is entirely random, sometimes not at all, but most of the time, some or all of the borders below the immidiately visible top part of the page will simply disappear.

Expected Results:  
borders should render accurately.

what seems to happen is, borders outside the immidiately visible portion of the page, sometimes do not get rendered. for example, borders will go missing from row 20 to the end of the table. the after a reload, borders will go missing from row 30 to the end of the table. where in the table the error begins, appears to be entirely random. sometimes (though rarely) there is no problem at all - but 9 out of 10 times, the problem does occur.

the page is produced by a script, but there are no variations in the script's output from one reload to another.

have compared the same page against Linux version of Firefox, the problem does not occur there, indicating a Windows-specific bug.

the page in question validates as XHTML/1.0 Strict:

http://validator.w3.org/check?uri=http%3A%2F%2Ftest.fyens.dk%2Fmodules%2Fclassdoc2%2Fadmin%2Fshow.php%3Fset%3D%252Fhome%252Fweb%252Fweb-fyens-test%252Fmodules%252Futil%252Funimailer.classdoc.txt&charset=%28detect+automatically%29&doctype=Inline&group=0

have tried changing border-width to 2 pixels, same problem occurs.

have tried disabling border-collapse, problem does not occur.

have tried file->save (complete) in firefox - the local copy of the page will contain lots of strict validation errors, such as not closing img-tags, but oddly enough will display correctly.

have also tried "view source", then saving the exact page output and putting that on the same server - strangle, the problem goes away.

have tried disabling the javascript on the page, and removing the floating table-of-contents in the right margin, but the problem persists.

I have been unable to find a work-around so far. Perhaps leaving my img-tags open like the "file->save as" function does, would work - but I'm required to follow standards, so that wouldn't help me.

Page renders correctly in IE 5.01, IE 5.5, IE 6.0, IE 7.0, Opera 9.21, and latest Firefox on Linux.

Comment 1

[Jesse Ruderman]

Bernd, is this a dup of bug 244135 even though there's no rowspan here?  If so, it would be good to remove "rowspan" from bug 244135's summary.

Comment 2

[Rasmus Schultz]

I thought maybe this would be due to colspan in this layout, so I tried removing all colspan attributes... same result though, with no spanning at all - doesn't seem to be span-related at all.

Suspecting that it might have something to do with the timing of loading additional files (since a local copy renders correctly), I've also tried removing all images ("net" tab in Firebug showed only 1 request) - but to no avail.

I figured it might be the backgrounds in the table-cells somehow being painted over the borders, so I disabled all background colors - still no luck.

Finally, the last thing I could think of, I disabled border-collapse - this seems to be the only thing that cures it. Of course it doesn't look anything like I want it to, so it's not even usable as a workaround, but it might give you a starting-point to look for some clues?

Comment 3

[Rasmus Schultz]

Okay, I have some more accurate information about this problem...

As said, it's related to border-collapse - this much I'm sure of.

If you've looked at my HTML in this document, you'll see that I have hidden (display:none) table-cells (<td>) within this table - and I'm using JavaScript to toggle these cells between display:none and display:table-cell. The problem occurs when the table-cells have display:none - if I change my CSS and remove that setting, the page renders correctly.

The hidden table-rows of this table look like this:

<tr><td colspan="2" id="row_id_xxx" class="classdoc_flyout">...<td></tr>

The class "classdoc_flyout" is the one that has the initial display:none attribute.

So I changed it as follows:

<tr id="row_id_xxx" class="classdoc_flyout"><td colspan="2">...<td></tr>

I updated the javascript to toggle the display attribute between 'table-row' and 'none' (instead of 'table-cell' and 'none'), and now it works!

So I think we can narrow it down to hidden table-cells in tables with collapsed borders.

You can see the broken version here: (same link as before)

http://test.fyens.dk/modules/classdoc2/admin/show.php?set=%2Fhome%2Fweb%2Fweb-fyens-test%2Fmodules%2Futil%2Funimailer.classdoc.txt

And adding "fix=1" will apply the workaround:

http://test.fyens.dk/modules/classdoc2/admin/show.php?fix=1&set=%2Fhome%2Fweb%2Fweb-fyens-test%2Fmodules%2Futil%2Funimailer.classdoc.txt

As described above, the interesting difference (for you) is simply that <tr> elements are initially hidden, instead of the <td> elements within them.

(by the way, this fix works in Opera and Firefox, but not in IE, since IE uses "block" as the default value of <tr>'s display attribute, so a small additional cross-browser workaround was needed here)

I hope this helps...

Comment 4

[Malcolm Parsons]

test.fyens.dk seems to be down.
Could you attach your testcase to the bug please.

Comment 5

[Rasmus Schultz]

sorry, yeah - the site came out of beta-testing and is running live now.

I've updated the URL - the updated URL to the fixed version is:

http://www.fyens.dk/modules/classdoc2/admin/show.php?fix=1&set=%2Fhome%2Fweb%2Fweb-fyens%2Fmodules%2Futil%2Funimailer.classdoc.txt

It's the same script as before, just use "fix=0" or "fix=1" to turn the workaround on/off...

Comment 6

[Malcolm Parsons]

This is not fixed by the patch in 244135.

Comment 7

[Malcolm Parsons]

Attachment: Testcase

Testcase using javascript to force reflow in a hidden table row.

Comment 8

[cyaugin]

Would it be possible to give this bug some priority for a fix? It's a very visible rendering error, as it messes up a lot of pages on Wikipedia.

Comment 9

[Bernd]

Attachment: reduced testcase

Comment 12

[Bernd]

this looks like it is WFM

Comment 13

[Stanimir Stamenkov]

Attachment: Structurally valid example

Still happens for me with latest Gecko versions.

Comment 17

[Marc Auslander]

bug: 950402 has been marked a duplicate of this very old bug.  But this just started a few nightly builds ago for me on the listed site.  And it's easy to see with http://www.sudokuslam.com/

As the comment on 950402 says, enlarging the image restores the vertical lines.

Comment 18

[Marc Auslander]

I was wrong - the bug is in 26 as well.  It just doesn't show up at the default size.  But reduce the size (ctrl-) and there it is.  So I assume I'm seeing it in the nightly because of some other scaling change that made it appear.

Comment 19

[elic]

attached examples look fine to me on Firefox 32 under Ubuntu.

Comment 21

[Elbart]

Attachment: Wikipedia example 2015-07-24

(In reply to elic from comment #19)
> attached examples look fine to me on Firefox 32 under Ubuntu.

The testcases work for me too (Nightly 2015-07-23), but this is showing the bug: 

https://en.wikipedia.org/wiki/List_of_Qualcomm_Snapdragon_devices#Snapdragon_800

https://en.wikipedia.org/w/index.php?title=List_of_Qualcomm_Snapdragon_devices&oldid=672885210#Snapdragon_800

Comment 22

[Gérard Talbot]

When I try attachment 336440 [details] with Firefox 59.0a1 buildID=20171210100145, I get expected results: table borders are rendered. I also see all table borders when trying attachment 549564 [details].

Comment 23

[Gérard Talbot]

I spent 2 hours reducing the table at

https://en.wikipedia.org/w/index.php?title=List_of_Qualcomm_Snapdragon_devices&oldid=672885210#Snapdragon_800

and then came up with this reduced test (2 rules, 2 declarations, 49 lines of code):

http://www.gtalbot.org/BugzillaSection/Bug398980-[BC]-table-border-bottom-randomly-missing.html

Now, Firefox 61 buildID=20180401100341 will not render a border-bottom for the cell with rowspan="3" while Chromium 64.0.3282.119 will. The cause of this must be the incorrect and too high rowspan attribute value in the code. I am not sure this is actually a bug. I have searched and read HTML 4.01 and CSS2.2 (§ 17.5 Visual layout of table contents) and there is nothing that states error correction mechanism for incorrect (too high) attribute rowspan specification. 

I do not know right now what HTML 5 says about this.

Comment 24

[Gérard Talbot]

(In reply to cyaugin from comment #8)
> a very visible rendering error, as it messes up a lot of pages on Wikipedia.

Elbart, cyaugin,

Go to 

https://en.wikipedia.org/w/index.php?title=List_of_Qualcomm_Snapdragon_devices&oldid=672885210#Snapdragon_800

then right-click inside the "28 nm HPm" cell and choose Examine element. You should see something like:

<td rowspan="5">28&#160;nm HPm</td>
<td rowspan="5">ARMv7</td>
<td rowspan="5">(...)</td>
<td rowspan="5">4</td>
<td rowspan="4">Up to 2.26</td>
<td rowspan="5">(...)</td>
<td rowspan="4">450</td>
<td rowspan="5">(...)</td>
<td rowspan="5">600</td>
<td rowspan="5"><a href="/wiki/LPDDR3" class="mw-redirect" title="LPDDR3">LPDDR3</a></td>
<td rowspan="5">32-bit dual-channel</td>

Now, change any (or all) those rowspan="5" to rowspan="4" by double-clicking on them in Inspector tool. Preferably, start with the left-most one: double-click the <td rowspan="5"> with "28 nm HPm" and then change the 5 to 4. And the border-bottom of any (or all) cells will appear.

Just by looking at the code, you can also see errors with the rowspan attribute specification: why does the cell with "28 nm HPm" states rowspan="5" when the cell with "Up to 2.26" declares rowspan="4"?

From the start, the multiple editors of such wikipedia page created very complex and large tables and *_they_* made a mistake with the rowspan attribute specification value in that table.

Comment 25

[Gérard Talbot]

I have created bug 1451157 (along with 2 tests) to cover the case defined in comment 23.

I am resolving this bug as WORKSFORME since we have confirmation that attachment 336440 [details] and attachment 549564 [details] are rendered accordingly.