Created attachment 88557 [details]
Images with max-height:100% are missing when they are inside blocks inside tables
See attached test case. It works fine in Firefox and IE.
I think this has something to do with this code in RenderBox::availableLogicalHeightUsing
if (isTableCell() && (h.isAuto() || h.isPercent()))
return overrideSize() - borderAndPaddingLogicalWidth();
In this case, if you check hasOverrideSize() you get false, and overrideSize just returns -1. So I think we need some kind of overrideLogical… method that's like the overrideHeight and overrideWidth methods that will check hasOverrideSize for you.
As a test, I just added a check of hasOverrideSize() to that condition, and it gets the image to the right size. That is probably overly simplistic though.
That experiment breaks tables/mozilla/bugs/bug137388-1.html so I'll use that test to understand how this code is supposed to work.
One thing that puzzles me is that the inner paragraph element is getting the right height. If I set the exact same height on the paragraph explicitly, then the image also gets the right size.
Sounds a bit similar to this old bug:
JPEG image not shown when height is specified as percentage inside a table
This also occurs with percentage-based height. Attaching a new test case.
Created attachment 89338 [details]
Now I'm thinking that the reason RenderTableSection's cell children flex code doesn't run is that percentHeightDescendants doesn't ever include this image element.
In http://trac.webkit.org/changeset/36513, Dan wrote this comment about code in RenderBox that adds to that list:
(WebCore::RenderBox::calcReplacedHeightUsing): Changed to skip over
anonymous containing blocks, if any, and when that happens, use
addPercentHeightDescendant() to ensure that the non-anonymous block
is aware of the dependent percent-height box.
In this case, because the containing block is never an anonymous block, we never add the image element to any RenderBox's list. I tried an experiment in RenderBox::computeReplacedLogicalHeightUsing to change that loop to a do while loop so the first containing block calls addPercentHeightDescendant even if its not an anonymous block. Again, this experiment fixed the original problem -- and broke the last test case in my attachment horribly. So maybe I'm off in the weeds here.
That experiment was a bust. Adding to percentHeightDescendant had no effect, but screwing up the concept of what is the containing block did.
Created attachment 91945 [details]
Extend the fix for bug 15359 to cover the nested case
Fixed in r85499. <http://trac.webkit.org/changeset/85499>