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

Bisect Information:
=====================
Good build: 52.0.2714.0    Revision(388674)
Bad Build : 52.0.2715.0    Revision(388964)

Change Log URL: 
https://chromium.googlesource.com/chromium/src/+log/6485a0d3465ba3b0bcca6385f8740a5c2e7c0138..5259539e7ebaad952477e740341742ec55556049

From the above change log suspecting below change
Review url: https://codereview.chromium.org/1899053002

dgrogan@ - 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.

Thanks...!!

Hi Gérard, thanks for the tests.

I *think* this issue is the same as issue 353580 (note that bzbarsky is the original author of http://jsfiddle.net/pCx89/4/ :)

+robhogan, who has done some work recently on these related bugs:

 issue 465096 
 issue 468699  (fallout from  issue 465096  attempt)
 issue 637811  (fremy and rob discussions)
 issue 687551  (more fremy/rob discussions about recent related spec changes)
issue 762330 (small fallout from  issue 687551 , probably irrelevant here)

maybe related discussion, earlier to later:
https://lists.w3.org/Archives/Public/www-style/2016Apr/0310.html
https://github.com/w3c/csswg-drafts/issues/1051
https://bugzilla.mozilla.org/show_bug.cgi?id=1417495
https://bugzilla.mozilla.org/show_bug.cgi?id=1186177

The bugzilla links mention that FF might have to change to blink's behavior, I'm guessing for better web compat? If so, then we should get some tests that precisely describe the difference in the current engines' behavior across all the related cases? (Maybe that's what your linked tests accomplish already? Sorry, only looked at them in chrome so far.)

In https://bugzilla.mozilla.org/show_bug.cgi?id=1186177#c9 you mention that blink's temporary chrome 50 behavior was correct, but I'm not sure that's true according to the latest css-tables-3 draft (really not sure, haven't looked into it yet).

I'll also have to look at the jsfiddle given in the revert for the temporarily-shipped behavior to see what the spec says about that case. IIRC, our temp behavior didn't match any other browsers.

If you've already dug into any of this, feel free to summarize here :)

If not, hopefully the links here will make it easier for me (or robhogan or anyone) to do so later, probably after the US holidays.

From my comment 9:
> If so, then we should get some tests that precisely describe the difference in the current engines' behavior across all the related cases

I meant to include:
After figuring out the difference in current implementations via those tests, use them to inform css-tables-3 about what it should prescribe.

> I *think* this issue is the same as issue 353580 

Yes, I agree... although I did not examine nested table case at all.

> The bugzilla links mention that FF might have to change to blink's behavior, 
> I'm guessing for better web compat?

Presumably, yes. Most likely.

> If so, then we should get some tests that precisely describe the difference in 
> the current engines' behavior across all the related cases? (Maybe that's what 
> your linked tests accomplish already? Sorry, only looked at them in chrome so 
> far.)

Unfortunately, I will not be able to help a lot on this as I am under Linux os.  I do not have access to Windows 10 (Edge 15+). 
I do not have access to Mac OS X 10.13 (Safari 11.x). 
Under more recent Linux, it is no longer possible to install the old Opera 12.16 (last version of Presto engine).

> In https://bugzilla.mozilla.org/show_bug.cgi?id=1186177#c9 you mention that 
> blink's temporary chrome 50 behavior was correct, but I'm not sure that's true 

That was an approximative extrapolation on my part (and not a factual verification) based on the understanding of comments that I looked at here and there in various Issues. I am most likely wrong or off by a few version number here or even totally wrong.

> tests, use them to inform css-tables-3 about what it should prescribe.

Yes. No problem to include, to submit those tests into the CSS3 Tables spec (presumably in section 3.10.2 [1]) and into an eventual CSS3-Tables test suite. 

[1]
"
(...) descendants of table cells whose height depends on percentages of their parent cell' height are considered to have an auto height if they have overflow set to visible or hidden or if they are replaced elements, and a 0px height if they have not.
"
CSS Table Module Level 3
W3C Working Draft, 7 March 2017
3.10.2. Row layout
https://www.w3.org/TR/css-tables-3/#row-layout

I think Chrome is correct here.

https://drafts.csswg.org/css-tables-3/#row-layout says:

"For the purpose of calculating [the minimum height of a row], descendants of table cells whose height depends on percentages of their parent cell's height are considered to have an auto height if they have overflow set to visible or hidden or if they are replaced elements, and a 0px height if they have not."

In the test case here (height-table-cell-011.xht) I think all the browsers are correctly calculating the row height and cell height as 100px. Where the behaviour differs is in what we do with the content of the cell. The text quoted above has no bearing on that, to my understanding.

I believe fremy summarizes the expected behaviour in: https://bugs.chromium.org/p/chromium/issues/detail?id=637811#c26 and the relevant bit is available in the amber break-out box at https://drafts.csswg.org/css-tables-3/#computing-the-table-height:

"Once the final size of the table and the rows has been determined, the content of the table-cells must also go through a second layout pass, where, if appropriate, percentage-based heights are this time resolved against their parent cell used height."

That's what Chrome is doing as far as I can tell: we're resolving the percentage value of the div against the 'used height' of the cell, which in this case is 100px.

I'm cc'ig fremy for his views.

Robert,

CSS2.1 is not compatible with WD CSS3 Tables with regards to table row height and table cell height: there is no second row layout pass algorithm in CSS2.1 and percentage do not apply to 'height' of table cells in CSS2.1. So far, I have not had a chance to carefully read both specs, 637811#c26 (and other issues) and examine tests done in CSS3 Tables. Chrome 62+ may be compliant with CSS3 Tables while Firefox 52+ is not.

I was under the impression that, this week, François Remy was going to confirm, to validate the expected results of the 7 tests listed in this Issue according to CSS3 Tables.

There is a lot to read and there will be a lot of tests needed, required to include in an eventual CSS3 Tables test suite.

This issue has been Available for over a year. If it's no longer important or seems unlikely to be fixed, please consider closing it out. If it is important, please re-triage the issue.

Sorry for the inconvenience if the bug really should have been left as Available.

For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot