Treat percent-height boxes inside auto-height cells as auto

third_party/WebKit/Source/core/layout/LayoutBox.cpp

 /*
  * Copyright (C) 1999 Lars Knoll (knoll@kde.org)
  *           (C) 1999 Antti Koivisto (koivisto@kde.org)
  *           (C) 2005 Allan Sandfeld Jensen (kde@carewolf.com)
  *           (C) 2005, 2006 Samuel Weinig (sam.weinig@gmail.com)
  * Copyright (C) 2005, 2006, 2007, 2008, 2009, 2010 Apple Inc. All rights reserved.
  * Copyright (C) 2013 Adobe Systems Incorporated. All rights reserved.
  *
  * This library is free software; you can redistribute it and/or
  * modify it under the terms of the GNU Library General Public
@@ skipping 2570 matching lines @@
     bool isOutOfFlowPositionedWithSpecifiedHeight = cb->isOutOfFlowPositioned() && (!cbstyle.logicalHeight().isAuto() || (!cbstyle.logicalTop().isAuto() && !cbstyle.logicalBottom().isAuto()));
 
     bool includeBorderPadding = isTable();
 
     if (isHorizontalWritingMode() != cb->isHorizontalWritingMode()) {
         availableHeight = containingBlockChild->containingBlockLogicalWidthForContent();
     } else if (hasOverrideContainingBlockLogicalHeight()) {
         availableHeight = overrideContainingBlockContentLogicalHeight();
     } else if (cb->isTableCell()) {
         if (!skippedAutoHeightContainingBlock) {
-            // Table cells violate what the CSS spec says to do with heights. Basically we
-            // don't care if the cell specified a height or not. We just always make ourselves
-            // be a percentage of the cell's current content height.
-            if (!cb->hasOverrideLogicalContentHeight()) {
+            // The second clause in this conditional (after the ||) is to support this line from the
+            // definition of height in CSS 2.2:
+            // "If the height of the containing block is not specified explicitly (i.e., it depends on
+            // content height), and this element is not absolutely positioned, the used height is
+            // calculated as if 'auto' was specified."
+            // But FF doesn't apply this logic (1) in quirks mode or (2) when "this element" is a table.

[mstensho (USE GERRIT), 2016/01/21 20:21:33]

https://dev.windows.com/en-us/microsoft-edge/tools/screenshots/#http://jsfidd...

Looks like this will make us more incompatible with MSIE (and Edge?), but it's
clearly more spec-compliant to do what you're doing, so let's just go ahead.

BTW: Presto applies this logic also when "this element" is a table. Less
weirdness. Not sure if we should dare to do the same, but if we *don't* want to
do that, we should add a test with a table with percent height inside a table in
strict mode, just to have this behavior covered.

[dgrogan, 2016/01/22 00:08:09]

Yeah, Edge shows the red square :(
I asked Boris on the bug why FF treats nested tables differently. Maybe it's in
some corner of the spec, a bug in FF, or just historical. What do you think of
using his answer as input to decide what to do?

[mstensho (USE GERRIT), 2016/01/22 10:15:36]

I still think we take the chance and land this change.
Where's his answer?

I don't think this is written in any spec, not even in dusty corners. :) This is
probably something FF did in order to be compatible with IE (or even Netscape)
on some site(s).

Regarding the strict behavior of Presto, I don't think we should make that
change right now, even if it's Right(TM). One step at a time. :) Maybe add a
TODO? I suggested that you add a test for this (table in table), but maybe
that's not necessary, since this is just some weirdness that we're not sure is
necessary.

[dgrogan, 2016/01/22 17:41:48]

His answer for now is "don't know, will ask around"
https://code.google.com/p/chromium/issues/detail?id=353580#c10 
TODO added. It's obliquely covered by an existing layout test
(fast/table/table-in-table-percent-width.html) but I agree that if we decide to
bake it into the platform it should have a dedicated layout test.

+            // Though I can't find documentation to support either of those.

[mstensho (USE GERRIT), 2016/01/21 20:21:33]

And I don't think you ever will. Because, tables!!! :) But I think you can
remove this line (move it to the commit message, if you like).

[dgrogan, 2016/01/22 00:08:09]

Done.

+            if (!cb->hasOverrideLogicalContentHeight() || (!document().inQuirksMode() && !isTable() && cbstyle.logicalHeight().isAuto())) {
                 // Normally we would let the cell size intrinsically, but scrolling overflow has to be
                 // treated differently, since WinIE lets scrolled overflow regions shrink as needed.
                 // While we can't get all cases right, we can at least detect when the cell has a specified
                 // height or when the table has a specified height. In these cases we want to initially have
                 // no size and allow the flexing of the table or the cell to its specified height to cause us
                 // to grow to fill the space. This could end up being wrong in some cases, but it is
                 // preferable to the alternative (sizing intrinsically and making the row end up too big).
                 LayoutTableCell* cell = toLayoutTableCell(cb);
                 if (scrollsOverflowY() && (!cell->style()->logicalHeight().isAuto() || !cell->table()->style()->logicalHeight().isAuto()))
                     return LayoutUnit();
@@ skipping 2289 matching lines @@
 }
 
 void LayoutBox::clearPreviousPaintInvalidationRects()
 {
     LayoutBoxModelObject::clearPreviousPaintInvalidationRects();
     if (PaintLayerScrollableArea* scrollableArea = this->scrollableArea())
         scrollableArea->clearPreviousPaintInvalidationRects();
 }
 
 } // namespace blink