Cope with intrinsic height styled on table cells

Source/core/layout/LayoutTableCell.h

Index: Source/core/layout/LayoutTableCell.h
diff --git a/Source/core/layout/LayoutTableCell.h b/Source/core/layout/LayoutTableCell.h
index 456cb3f6f5fefb0786bd8f132659c7fc852152cd..ddad9cd7dcf47739c58ecaabca4e5439181cd554 100644
--- a/Source/core/layout/LayoutTableCell.h
+++ b/Source/core/layout/LayoutTableCell.h
@@ -100,9 +100,16 @@ public:
         return styleWidth;
     }
 
+    int computeLogicalHeightFromCellStyle(const Length& height) const
+    {
+        if (height.isIntrinsic())
+            return computeIntrinsicLogicalContentHeightUsing(height, logicalHeight() - borderAndPaddingLogicalHeight(), borderAndPaddingLogicalHeight());
+        return valueForLength(height, 0);
+    }
+
     int logicalHeightFromStyle() const
     {
-        int styleLogicalHeight = valueForLength(style()->logicalHeight(), 0);
+        int styleLogicalHeight = computeLogicalHeightFromCellStyle(style()->logicalHeight());

[mstensho (USE GERRIT), 2015/07/07 07:11:39]

Any reason why we shouldn't just treat intrinsic values as auto? I know
intrinsic and auto isn't the same, but I don't see any point in treating them
differently inside tables. There's no table spec that defines how to treat
intrinsic height values, as far as I know. Tables and fancy height property
values are two technologies that never met, very much like 5.25" floppy drives
and USB ports.

[rhogan, 2015/07/07 18:40:02]

Sure, but we treat them this way when they're set on the table itself, see
LayoutTable::convertStyleLogicalHeightToComputedHeight() and co. So at least
we're being internally consistent this way. :)

         // In strict mode, box-sizing: content-box do the right thing and actually add in the border and padding.
         // Call computedCSSPadding* directly to avoid including implicitPadding.
         if (!document().inQuirksMode() && style()->boxSizing() != BORDER_BOX)