Fix incorrect percentage top for positioned elements.

Source/core/layout/LayoutBox.cpp

Index: Source/core/layout/LayoutBox.cpp
diff --git a/Source/core/layout/LayoutBox.cpp b/Source/core/layout/LayoutBox.cpp
index b87d2138d1fcd54f189a0096ba5c5f9adb6514d1..eecac2c8dda0fe8e46c05f5be1e67c5d6ee42ed1 100644
--- a/Source/core/layout/LayoutBox.cpp
+++ b/Source/core/layout/LayoutBox.cpp
@@ -2717,12 +2717,12 @@ LayoutUnit LayoutBox::availableLogicalHeightUsing(const Length& h, AvailableLogi
         return adjustContentBoxLogicalHeightForBoxSizing(newContentHeight);
     }
 
-    // FIXME: This is wrong if the containingBlock has a perpendicular writing mode.

[rune, 2015/03/16 13:34:03]

You removed this FIXME. Is it fixed?

-    LayoutUnit availableHeight = containingBlockLogicalHeightForContent(heightType);
-    if (heightType == ExcludeMarginBorderPadding) {
-        // FIXME: Margin collapsing hasn't happened yet, so this incorrectly removes collapsed margins.

[rune, 2015/03/16 13:34:03]

You removed this FIXME. Is it fixed?

-        availableHeight -= marginBefore() + marginAfter() + borderAndPaddingLogicalHeight();
-    }
+    const LayoutBlock* cb = isLayoutBlock() ? toLayoutBlock(this) : containingBlock();

[mstensho (USE GERRIT), 2015/03/23 14:27:55]

Pretending that we're our own containing block? This makes no sense.

As far as I can tell, the only thing you want to change is resolving percentage
top/bottom values from computedStyle, to increase browser interoperability. Then
I don't think this method should be changed at all, since it's also called
during layout. The changes here cause quite a few test regressions.

[changseok, 2015/03/26 07:12:04]

Agree. I looked into this area more. I don't know the history of
containingBlockLogicalHeight , but what I can tell you is it is too much complex
over its name. Actually containingBlockLogicalWidth works more simple.
containingBlockLogicalWidthForContent -> availableLogicalWidth -> 
contentLogicalWidth -> contentWidth

In the other hand.
containingBlockLogicalHeightForContent -> availableLogicalHeight ->
availableLogicalHeightUsing -> containingBlockLogicalHeightForContent -> ... ->
eventually the height of viewport returned where containingBlock is static or
relative or absolute.

So I think getting content height from containingBlockLogicalHeightForContent is
not proper. It might be originally designed for this purpose, but not anymore.
Fixing this method may not be a good idea as you pointed out. It has been used
some places and involved in layout. Rather, adding a new method returning
immediate containingBlock's content height or padding box height is better for
percentage top.

[mstensho (USE GERRIT), 2015/03/26 12:53:37]

Yeah, but resolving percentage heights isn't as simple as resolving percentage
widths. If the containing block has auto height, for instance...

+    LayoutUnit availableHeight = cb->clientLogicalHeight();

[rune, 2015/03/16 13:34:03]

This seems quite different from containingBlockLogicalHeightForContent(). If the
need for this change can be observed as bugs, you should add some more
testcases.

I don't quite follow this. Some layout code owner should take over reviewing, I
think.

[changseok, 2015/03/26 07:12:04]

Yeah.. I think containingBlockLogicalHeightForContent is too complex to get
contentHeight of containing block. We might need a more simple method for it.
O.K Thanks anyway ;)

+    if (heightType == ExcludeMarginBorderPadding)
+        availableHeight -= paddingBefore() + paddingAfter();
+    else if (heightType == IncludeMarginBorderPadding)
+        availableHeight += marginBefore() + marginAfter() + borderBefore() + borderAfter();
     return availableHeight;
 }