FAIL:
Expected 82 for width, but got 100. 
Expected 78 for width, but got 96. 

https://storage.googleapis.com/chromium-layout-test-archives/WebKit_Mac10_9/39765/layout-test-results/fast/table/percent-height-replaced-content-in-cell-pretty-diff.html

Maybe we just have to wait for the load event before calling checkLayout? I admit that I'm not at all familiar with what this is testing and don't know if something deeper is amiss.

I actually removed all the testing cruft from the test and put a pink background on the table. Then I observed with my own eyes that the table width wasn't the same on every load. So this looks like a pure layout bug to me. It probably has to do with the timing of image loading (whether we get to lay out once before the image arrives, and then have to relayout), but I haven't debugged it any further.

That sounds bad but I'm glad the test caught it!

Another flaky table test with images:  issue 713050 .

Chrome/Edge differ with FF on this one. I think FF has it right, the image should be auto sized:
https://jsfiddle.net/m2akxz4t/5/

This is probably a better case for illustrating our flakiness:
https://jsfiddle.net/m2akxz4t/6/

Even though the image sizes up to fill the cell (height scaling up the width) I don't believe it should ever cause the width of the table to exceed the intrinsic width of the image, and that's what we sometimes do. That's our bug I think.

Hey Robert,

I was aware of this case. The spec currently backs Edge/Chrome behavior fwiw:

> It is appropriate to resolve percentage heights 
> on direct children of table cells 
> if the cell is considered to have its height specified explicitly
> or the element is absolutely positioned
> see CSS 2.
> 
> It is further clarified that 
> a cell is considered to have its height specified explicitly
> if the computed height of the cell 
> or any of its table ancestors
> is a length or percentage.

(with the caveat that "computed" here currently refers to the CSS 2 computed value, so percentages are only considered if they actually apply (and would compute to a percentage under CSS 2 rules)

I would rather keep that statement as-is just based on the fact a majority of browser engines behave that way, and Firefox already has bugs to fix in the area to achieve interop so implementing this behavior shouldn't take them any additional time.

I know that the above statement also implies tbody/tr height should be taken into account but I believe this is the right thing to do for tr anyway (since the height of a td applies on the tr not the td, and tbody has been resolved to work similarly to a mini-table for its contained rows). That part on tr and tbody hasn't got a working group resolution though, so if anyone feel strongly it can be reverted.

WDYT?

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/03d66d9ce1e602df26a9d544d9258a88b9194349

commit 03d66d9ce1e602df26a9d544d9258a88b9194349
Author: robhogan <robhogan@gmail.com>
Date: Tue May 16 22:15:17 2017

Ensure cell's replaced content doesn't get the wrong width

We need to make the cell's height unusable for calculating perecent/calc height
against before computing its preferred width, otherwise replaced children may use it
to scale up their intrinsic width.

BUG=666730

Review-Url: https://codereview.chromium.org/2851513004
Cr-Commit-Position: refs/heads/master@{#472228}

[modify] https://crrev.com/03d66d9ce1e602df26a9d544d9258a88b9194349/third_party/WebKit/LayoutTests/fast/table/percent-height-replaced-content-in-cell.html
[modify] https://crrev.com/03d66d9ce1e602df26a9d544d9258a88b9194349/third_party/WebKit/Source/core/layout/LayoutTableCell.cpp

 Issue 707918  has been merged into this issue.

Looks like that change didn't update the -expected.txt but survived the CQ because the test was already marked flaky in TestExpectations.

 Issue 671478  has been merged into this issue.

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/3a7aae34f9467403d5043cc42249d24b92f98737

commit 3a7aae34f9467403d5043cc42249d24b92f98737
Author: David Grogan <dgrogan@chromium.org>
Date: Thu Mar 29 18:27:12 2018

[css-tables] Rebase test that got missed a year ago

Bug: 666730
Change-Id: I94fa35185021d6c842eb9e2efa3e1b844f3e4f97
Reviewed-on: https://chromium-review.googlesource.com/985640
Reviewed-by: Morten Stenshorne <mstensho@chromium.org>
Commit-Queue: David Grogan <dgrogan@chromium.org>
Cr-Commit-Position: refs/heads/master@{#546856}
[modify] https://crrev.com/3a7aae34f9467403d5043cc42249d24b92f98737/third_party/WebKit/LayoutTests/FlagExpectations/disable-blink-features=RootLayerScrolling
[modify] https://crrev.com/3a7aae34f9467403d5043cc42249d24b92f98737/third_party/WebKit/LayoutTests/TestExpectations
[modify] https://crrev.com/3a7aae34f9467403d5043cc42249d24b92f98737/third_party/WebKit/LayoutTests/fast/table/percent-height-replaced-content-in-cell-expected.txt