Able to reproduce the issue on Windows 10, mac 10.12.6 and Ubuntu 14.04 using chrome reported version #62.0.3202.94 and latest canary #64.0.3279.0.

Bisect Information:
=====================
Good build: 62.0.3185.0    Revision(494002)
Bad Build : 62.0.3186.0    Revision(494273)

Change Log URL: 
https://chromium.googlesource.com/chromium/src/+log/d88adacb7803429007f81f62824b60c0f4b4358a..246a8e989506c7fe342fdd02adf2dee8420ab641

From the above change log suspecting below change
Change-Id: Ib143f5601afb075d973bca8b2e33e922a5be7f4b
Reviewed-on: https://chromium-review.googlesource.com/614461

eae@ - Could you please check whether this is caused with respect to your change, if not please help us in assigning it to the right owner.
Note: 
1. Assigning it to the reviewer of the issue as the author i.e joysyu@ mail seems to be bounced.
2. Adding stable blocker for M-64 and requesting to merge the fix( (if its safe merge) to M-63

Thanks...!!

Still seeing the same issue on latest canary versions-65.0.3284.0 & 64.0.3282.8 on Windows 7,Mac 10.12.6 & ubuntu 14.04 as per C#0.

dgrogan@, Could you please take a look and update the thread accordingly.

Thanks..!

Friendly ping to get an update on this issue as it is marked as stable blocker.
Thanks..!

I think it doesn't have to block 64: we already shipped it in 62 and 63, there hasn't been widespread damage, and 64 already branched. I'd want the fix to get a full cycle of testing.

krajshree, why did you mark this RB-Stable?

I'll try to get the fix in for 65.

Any news on this?

@c9, no updates. It would be helpful if you could produce a reduced testcase as described in https://developers.google.com/web/feedback/file-a-bug#create_a_minimized_test_case

I am not a developer.  I did not develop that website.  I am just reporting a bug in chrome and with the URL I supplied, along with the screenshots of what it looks like and what it should look like, I think the problem is pretty clear.

As it is now, we are just telling our clients to use another browser.  Since I am a chrome fan, I would rather not do that, but right now there is little choice.  I posted the last comment because I did not see any activity since Dec 11.

Hi guys,

Just wanted to let you know that we have quite a few people from the international community visiting our site, and it's unfortunate that we have to tell them not to use Chrome because of this bug.  I was disappointed to see that this bug is still present with the latest update. Any progress towards fixing it? 

No progress. If that is your website, you can help speed up the process by having whoever developed it supply a reduced testcase, even if you yourself are not in a position to do so.

It was developed by the OECD. 

http://www.oecd.org/

I doubt they will put in any resources to help you debug your software.  Sorry.  NGOs are very bureaucratic, and it's not their software that has the issue, it's yours.

I know this is frustrating, and we'll try to tackle it soon, we're just oversubscribed.

> it's not their software that has the issue, it's yours.

This is *probably* true, but far from a sure thing.

Just FYI, the earliest this will get fixed is Chrome 67, which is released to the stable channel (probably the channel most of your users use) at the end of May or early June.

Well, that issue is certainly absent in any of the other browsers, so I am putting my money on it being a chrome issue.

I will do what I can to help you.  If I do get in touch with their dev team, I will ask them for a test case, but they are normally not very responsive (very small team supporting a very large organization).

Thanks for the feedback.

Internal project bookkeeping info: this is a P2 (not P3) because it is an "Unexpected, correctness regression"

Arg, not going to get to this by 68.

I spent some quality time with http://data.uis.unesco.org/ today. Turns out the bug is in the site, not chrome.

The site authors assumed that neither Chrome (nor Safari) would ever implement a certain css feature, and built the page differently for Chrome and Safari vs other browsers. This practice is generally discouraged but sometimes necessary (at first blush, it appears to have been unnecessary in this case -- visibility:collapse had been interpreted as hidden, why not set hidden for all browsers? -- but I'm not certain.)

Last year Chrome DID implement the feature (visibility:collapse on table rows -- issue 174167), invalidating the site authors' assumption and breaking the site.

The chrome-specific code is in http://data.uis.unesco.org/js/default.js?v2 , approximately lines 235-240 and 261-264 :
            if ($.browser.webkit) {
                $("#fixedheader").css("visibility", "collapse");
            }
            else {
                $("#fixedheader tbody, #fixedheader th.HDim, #fixedheader th.SiblingMD").css("visibility", "hidden");
            }
...

            if ($.browser.webkit) {
                $("#columnlabels").css("visibility", "collapse");
                $("#rowlabels").css("visibility", "collapse");
            }

You can see the effect these lines have by negating them in chrome by running these commands in the devtools console (ctrl shift I):
$("#rowlabels").css("visibility", "")
$("#columnlabels").css("visibility", "")
$("#fixedheader").css("visibility", "")

I encourage you to escalate to whoever runs the site -- the fix should be very easy to serve the same content to chrome as Firefox and Edge.

Closing the bug as WorksAsIntended but feel free to respond back or open a new bug if there are further issues.