Absolute positioned child with percent should include containing block padding

Absolute positioned child with percent should include containing block padding

The padding box of the containing block is to be used for absolutely
positioned descendants. But this rule is not applied yet. This CL
fixes 2 issue.
1. getComputedStyle on absolute positioned child with percent-based
left has to use containing block which includes padding box.
2. Absolute positioned child with percent-based padding also has to
use containing block which includes padding box.

BUG=601030
Committed: https://crrev.com/9908f45b70b65fc242e050d33c67294fe870a1cb
Cr-Commit-Position: refs/heads/master@{#393358}

[Deokjin Kim, 2016-04-14 15:00:57]

Description was changed from

==========
WIP

BUG=601030
==========

to

==========
Because child element is on absolute position, parent element's
padding is not needed for calculating containing block's width.
    
BUG=601030
==========

[Deokjin Kim, 2016-04-14 15:00:58]

deokjin81.kim@samsung.com changed reviewers:
+ alancutter@chromium.org, esprehn@chromium.org, kojii@chromium.org,
rune@opera.com, timloh@chromium.org

[Deokjin Kim, 2016-04-14 15:02:06]

PTAL. Thank you in advance.

[esprehn, 2016-04-14 18:40:58]

Description was changed from

==========
Because child element is on absolute position, parent element's
padding is not needed for calculating containing block's width.
    
BUG=601030
==========

to

==========
getComputedStyle on absolute position has to return correct left

Because child element is on absolute position, parent element's
padding is not needed for calculating containing block's width.
    
BUG=601030
==========

[esprehn, 2016-04-14 18:43:09]

Please write your patch description has a subject, then a new line, then the
description. That;s different from the codereview subject. I fixed this one for
you.

Why is getComputedStyle manually resolving percentages like this? Shouldn't the
frameRect of the LayoutBox tell you the correct information?

All of these ForComputedStyle getters seem kind of sketchy.

https://codereview.chromium.org/1876123002/diff/40001/third_party/WebKit/Sour...
File third_party/WebKit/Source/core/css/ComputedStyleCSSValueMapping.cpp (left):

https://codereview.chromium.org/1876123002/diff/40001/third_party/WebKit/Sour...
third_party/WebKit/Source/core/css/ComputedStyleCSSValueMapping.cpp:189:
toLayoutBox(layoutObject)->containingBlockLogicalWidthForContent() :
this is used in multiple other places in CSSValueMapping.cpp, are they wrong
too?

https://codereview.chromium.org/1876123002/diff/40001/third_party/WebKit/Sour...
File third_party/WebKit/Source/core/layout/LayoutBox.cpp (right):

https://codereview.chromium.org/1876123002/diff/40001/third_party/WebKit/Sour...
third_party/WebKit/Source/core/layout/LayoutBox.cpp:1617: LayoutBoxModelObject*
cb = toLayoutBoxModelObject(container());
why is container correct vs containingBlock?

[Deokjin Kim, 2016-04-20 13:34:09]

Description was changed from

==========
getComputedStyle on absolute position has to return correct left

Because child element is on absolute position, parent element's
padding is not needed for calculating containing block's width.
    
BUG=601030
==========

to

==========
getComputedStyle on absolute position has to return correct left

Because child element is on absolute position, containing
block's width has to include padding.
    
BUG=601030
==========

[Deokjin Kim, 2016-04-20 13:42:09]

I updated to use the frameRect of the LayoutBox instead of ForComputedStyle
getter. If element is not table and position is absolute, then use containing
box's width which includes padding. Would you please review this CL?

https://codereview.chromium.org/1876123002/diff/40001/third_party/WebKit/Sour...
File third_party/WebKit/Source/core/css/ComputedStyleCSSValueMapping.cpp (left):

https://codereview.chromium.org/1876123002/diff/40001/third_party/WebKit/Sour...
third_party/WebKit/Source/core/css/ComputedStyleCSSValueMapping.cpp:189:
toLayoutBox(layoutObject)->containingBlockLogicalWidthForContent() :
On 2016/04/14 18:43:09, esprehn wrote:
> this is used in multiple other places in CSSValueMapping.cpp, are they wrong
> too?

On PS#7 this change is not needed anymore because we use
containingBlockLogicalWidthForContent(), not
containingBlockLogicalWidthForGetComputedStyle().

https://codereview.chromium.org/1876123002/diff/40001/third_party/WebKit/Sour...
File third_party/WebKit/Source/core/layout/LayoutBox.cpp (right):

https://codereview.chromium.org/1876123002/diff/40001/third_party/WebKit/Sour...
third_party/WebKit/Source/core/layout/LayoutBox.cpp:1617: LayoutBoxModelObject*
cb = toLayoutBoxModelObject(container());
On 2016/04/14 18:43:09, esprehn wrote:
> why is container correct vs containingBlock?

I think this issue is caused by the difference between clientLogicalWidth() and
availableLogicalWidth(). clientLogicalWidth() includes padding, but
availableLogicalWidth() doesn't include padding.

[esprehn, 2016-04-25 23:12:33]

The CQ bit was checked by esprehn@chromium.org to run a CQ dry run

[commit-bot: I haz the power, 2016-04-25 23:13:10]

Dry run: CQ is trying da patch. Follow status at
 https://chromium-cq-status.appspot.com/patch-status/1876123002/120001
View timeline at
 https://chromium-cq-status.appspot.com/patch-timeline/1876123002/120001

[commit-bot: I haz the power, 2016-04-26 00:29:15]

The CQ bit was unchecked by commit-bot@chromium.org

[commit-bot: I haz the power, 2016-04-26 00:29:16]

Dry run: This issue passed the CQ dry run.

[Deokjin Kim, 2016-04-28 00:26:56]

@esprehn, would you please review this CL? If you have any concerns about this
CL, please let me know. Thank you~

[Deokjin Kim, 2016-05-10 11:50:07]

PTAL. Thank you in advance.

[alancutter (OOO until 2018), 2016-05-11 00:29:42]

Removing myself from reviewers as I don't have ownership over layout code.
You probably want someone from third_party/WebKit/Source/core/layout/OWNERS to
review this change.

[Deokjin Kim, 2016-05-11 01:04:27]

deokjin81.kim@samsung.com changed reviewers:
+ eae@chromium.org, mstensho@opera.com

[Deokjin Kim, 2016-05-11 01:11:46]

PTAL, Thank you. I added 2 more reviewers(eae, mstensho).

[mstensho (USE GERRIT), 2016-05-11 08:36:22]

https://codereview.chromium.org/1876123002/diff/120001/third_party/WebKit/Lay...
File
third_party/WebKit/LayoutTests/fast/css/getComputedStyle/getComputedStyle-left.html
(right):

https://codereview.chromium.org/1876123002/diff/120001/third_party/WebKit/Lay...
third_party/WebKit/LayoutTests/fast/css/getComputedStyle/getComputedStyle-left.html:12:
padding: 0 10%;
I don't think you need to use percents here (they are indirectly resolved
against the browser window size, which isn't so nice). Please use pixels
instead, and then also get rid of the box-sizing:border-box universal selector
above.

https://codereview.chromium.org/1876123002/diff/120001/third_party/WebKit/Sou...
File third_party/WebKit/Source/core/layout/LayoutBox.cpp (right):

https://codereview.chromium.org/1876123002/diff/120001/third_party/WebKit/Sou...
third_party/WebKit/Source/core/layout/LayoutBox.cpp:1630: if (!isTable() &&
styleRef().position() == AbsolutePosition)
Why not for tables?

And rather than "styleRef().position() == AbsolutePosition", you could say
"isOutOfFlowPositioned()".

https://codereview.chromium.org/1876123002/diff/120001/third_party/WebKit/Sou...
third_party/WebKit/Source/core/layout/LayoutBox.cpp:1631: return
cb->clientLogicalWidth();
Right, the padding box (and not the content box) of the containing block is to
be used for absolutely positioned descendants, but that's a very fundamental
thing in layout. Makes you wonder how we survived without this check in the
past, doesn't it? Surely we were already able to lay out absolutely positioned
objects correctly?

Looks like containingBlockLogicalWidthForContent() isn't called much at all for
absolutely positioned descendants. See e.g. LayoutBox::computeLogicalWidth(),
where we perform an early check for isOutOfFlowPositioned() and defer to
computePositionedLogicalWidth() for such objects, which doesn't involve calling
containingBlockLogicalWidthForContent(), at least not directly.

However, if the absolutely positioned child has percent-based padding,
containingBlockLogicalWidthForContent() *is* involved to resolve the
percentages, and you're (inadvertently?) fixing an old layout bug here, which it
seems we have no test coverage for.

Here's what you fixed:

<!DOCTYPE html>
<p>The word "PASS" should be seen below, to the right of a black rectangle.</p>
<div style="position:relative; padding:2em; width:4em; color:black;
background:black;">
    <div style="position:absolute; left:0; top:0; padding-left:100%;">PASS</div>
</div>

We need a layout test for this as well, and the description needs to be updated,
since you're fixing more than what you claim. :)

[Deokjin Kim, 2016-05-11 13:58:22]

Description was changed from

==========
getComputedStyle on absolute position has to return correct left

Because child element is on absolute position, containing
block's width has to include padding.
    
BUG=601030
==========

to

==========
getComputedStyle on absolute position has to return correct value
    
The padding box of the containing block is to be used for absolutely positioned
descendants. On current implementation, containing block's width doesn't include
padding. And this CL has 2 test cases. One is for percent-based left, the other
is for percent-based padding.
    
BUG=601030
==========

[Deokjin Kim, 2016-05-11 13:58:36]

Description was changed from

==========
getComputedStyle on absolute position has to return correct value
    
The padding box of the containing block is to be used for absolutely positioned
descendants. On current implementation, containing block's width doesn't include
padding. And this CL has 2 test cases. One is for percent-based left, the other
is for percent-based padding.
    
BUG=601030
==========

to

==========
getComputedStyle on absolute position has to return correct value.
    
The padding box of the containing block is to be used for absolutely positioned
descendants. On current implementation, containing block's width doesn't include
padding. And this CL has 2 test cases. One is for percent-based left, the other
is for percent-based padding.
    
BUG=601030
==========

[Deokjin Kim, 2016-05-11 13:59:10]

Description was changed from

==========
getComputedStyle on absolute position has to return correct value.
    
The padding box of the containing block is to be used for absolutely positioned
descendants. On current implementation, containing block's width doesn't include
padding. And this CL has 2 test cases. One is for percent-based left, the other
is for percent-based padding.
    
BUG=601030
==========

to

==========
getComputedStyle on absolute position has to return correct value.
    
The padding box of the containing block is to be used for absolutely
positioned descendants. On current implementation, containing block's
width doesn't include padding. And this CL has 2 test cases. One is
for percent-based left, the other is for percent-based padding.
    
BUG=601030
==========

[Deokjin Kim, 2016-05-11 14:10:04]

Thank you for your review. I changed code and test-case according to your guide
and added 1 more test-case for percent-based padding. Would you please review
this CL?

https://codereview.chromium.org/1876123002/diff/120001/third_party/WebKit/Lay...
File
third_party/WebKit/LayoutTests/fast/css/getComputedStyle/getComputedStyle-left.html
(right):

https://codereview.chromium.org/1876123002/diff/120001/third_party/WebKit/Lay...
third_party/WebKit/LayoutTests/fast/css/getComputedStyle/getComputedStyle-left.html:12:
padding: 0 10%;
On 2016/05/11 08:36:22, mstensho wrote:
> I don't think you need to use percents here (they are indirectly resolved
> against the browser window size, which isn't so nice). Please use pixels
> instead, and then also get rid of the box-sizing:border-box universal selector
> above.

Done.

https://codereview.chromium.org/1876123002/diff/120001/third_party/WebKit/Sou...
File third_party/WebKit/Source/core/layout/LayoutBox.cpp (right):

https://codereview.chromium.org/1876123002/diff/120001/third_party/WebKit/Sou...
third_party/WebKit/Source/core/layout/LayoutBox.cpp:1630: if (!isTable() &&
styleRef().position() == AbsolutePosition)
On 2016/05/11 08:36:22, mstensho wrote:
> Why not for tables?
In case of tables, even though the absolute positioned child has percent-based
width/height, containing block's width doesn't need to include padding. In fact,
without "!Table()", test case "fast/table/absolute-table-percent-lengths.html"
is failed.

> And rather than "styleRef().position() == AbsolutePosition", you could say
> "isOutOfFlowPositioned()".

Done.

https://codereview.chromium.org/1876123002/diff/120001/third_party/WebKit/Sou...
third_party/WebKit/Source/core/layout/LayoutBox.cpp:1631: return
cb->clientLogicalWidth();
On 2016/05/11 08:36:22, mstensho wrote:
> Right, the padding box (and not the content box) of the containing block is to
> be used for absolutely positioned descendants, but that's a very fundamental
> thing in layout. Makes you wonder how we survived without this check in the
> past, doesn't it? Surely we were already able to lay out absolutely positioned
> objects correctly?

First time I thought that this code is only used for getComputedStyle. To answer
your question, I need more time for investigation. :)

> Looks like containingBlockLogicalWidthForContent() isn't called much at all
for
> absolutely positioned descendants. See e.g. LayoutBox::computeLogicalWidth(),
> where we perform an early check for isOutOfFlowPositioned() and defer to
> computePositionedLogicalWidth() for such objects, which doesn't involve
calling
> containingBlockLogicalWidthForContent(), at least not directly.
> 
> However, if the absolutely positioned child has percent-based padding,
> containingBlockLogicalWidthForContent() *is* involved to resolve the
> percentages, and you're (inadvertently?) fixing an old layout bug here, which
it
> seems we have no test coverage for.
> 
> Here's what you fixed:
> 
> <!DOCTYPE html>
> <p>The word "PASS" should be seen below, to the right of a black
rectangle.</p>
> <div style="position:relative; padding:2em; width:4em; color:black;
> background:black;">
>     <div style="position:absolute; left:0; top:0;
padding-left:100%;">PASS</div>
> </div>

Done.

> We need a layout test for this as well, and the description needs to be
updated,
> since you're fixing more than what you claim. :)

Done.

[mstensho (USE GERRIT), 2016-05-12 09:34:03]

I think that you still need to work a little on the description. This isn't
specific to getComputedStyle() anymore.

https://codereview.chromium.org/1876123002/diff/120001/third_party/WebKit/Sou...
File third_party/WebKit/Source/core/layout/LayoutBox.cpp (right):

https://codereview.chromium.org/1876123002/diff/120001/third_party/WebKit/Sou...
third_party/WebKit/Source/core/layout/LayoutBox.cpp:1630: if (!isTable() &&
styleRef().position() == AbsolutePosition)
On 2016/05/11 14:10:04, Deokjin Kim wrote:
> On 2016/05/11 08:36:22, mstensho wrote:
> > Why not for tables?
> In case of tables, even though the absolute positioned child has percent-based
> width/height, containing block's width doesn't need to include padding. In
fact,
> without "!Table()", test case "fast/table/absolute-table-percent-lengths.html"
> is failed.

That's weird. I don't think there's anything in the spec that suggests such
behavior.
We need to figure out why this happens. It's too unsettling to accept without a
good explanation.

https://codereview.chromium.org/1876123002/diff/140001/third_party/WebKit/Lay...
File
third_party/WebKit/LayoutTests/fast/css/getComputedStyle/getComputedStyle-left.html
(right):

https://codereview.chromium.org/1876123002/diff/140001/third_party/WebKit/Lay...
third_party/WebKit/LayoutTests/fast/css/getComputedStyle/getComputedStyle-left.html:8:
padding: 0px 0px;
That's the initial value for padding. You can just drop this declaration.

https://codereview.chromium.org/1876123002/diff/140001/third_party/WebKit/Lay...
File
third_party/WebKit/LayoutTests/fast/css/getComputedStyle/getComputedStyle-padding-expected.html
(right):

https://codereview.chromium.org/1876123002/diff/140001/third_party/WebKit/Lay...
third_party/WebKit/LayoutTests/fast/css/getComputedStyle/getComputedStyle-padding-expected.html:4:
position: relative;
This can be simplified. It's just a ref. A simple black 8em * 4em float followed
by "PASS" should do, right?

https://codereview.chromium.org/1876123002/diff/140001/third_party/WebKit/Lay...
File
third_party/WebKit/LayoutTests/fast/css/getComputedStyle/getComputedStyle-padding.html
(right):

https://codereview.chromium.org/1876123002/diff/140001/third_party/WebKit/Lay...
third_party/WebKit/LayoutTests/fast/css/getComputedStyle/getComputedStyle-padding.html:1:
<!DOCTYPE html>
The file name is misleading. This has nothing to do with getComputedStyle.

[Deokjin Kim, 2016-05-12 11:14:51]

Description was changed from

==========
getComputedStyle on absolute position has to return correct value.
    
The padding box of the containing block is to be used for absolutely
positioned descendants. On current implementation, containing block's
width doesn't include padding. And this CL has 2 test cases. One is
for percent-based left, the other is for percent-based padding.
    
BUG=601030
==========

to

==========
Absolute positioned child with percent should return correct value
    
The padding box of the containing block is to be used for absolutely
positioned descendants. But this rule is not applied yet. This CL
fixes 2 issue.
1. getComputedStyle on absolute positioned child with percent-based
left has to use containing block which includes padding box.
2. Absolute positioned child with percent-based padding also has to
use containing block which includes padding box.
    
BUG=601030
==========

[Deokjin Kim, 2016-05-12 11:24:20]

I modified description and fixed table issue. Would you please review this CL?
Thank you~

https://codereview.chromium.org/1876123002/diff/120001/third_party/WebKit/Sou...
File third_party/WebKit/Source/core/layout/LayoutBox.cpp (right):

https://codereview.chromium.org/1876123002/diff/120001/third_party/WebKit/Sou...
third_party/WebKit/Source/core/layout/LayoutBox.cpp:1630: if (!isTable() &&
styleRef().position() == AbsolutePosition)
On 2016/05/12 09:34:03, mstensho wrote:
> On 2016/05/11 14:10:04, Deokjin Kim wrote:
> > On 2016/05/11 08:36:22, mstensho wrote:
> > > Why not for tables?
> > In case of tables, even though the absolute positioned child has
percent-based
> > width/height, containing block's width doesn't need to include padding. In
> fact,
> > without "!Table()", test case
"fast/table/absolute-table-percent-lengths.html"
> > is failed.
> 
> That's weird. I don't think there's anything in the spec that suggests such
> behavior.
> We need to figure out why this happens. It's too unsettling to accept without
a
> good explanation.

In updateLogicalWidth() of LayoutTable.cpp, if absolute or fixed, then add
paddingLogicalWidth 1 more time. I think this code is not needed anymore.

https://codereview.chromium.org/1876123002/diff/140001/third_party/WebKit/Lay...
File
third_party/WebKit/LayoutTests/fast/css/getComputedStyle/getComputedStyle-left.html
(right):

https://codereview.chromium.org/1876123002/diff/140001/third_party/WebKit/Lay...
third_party/WebKit/LayoutTests/fast/css/getComputedStyle/getComputedStyle-left.html:8:
padding: 0px 0px;
On 2016/05/12 09:34:03, mstensho wrote:
> That's the initial value for padding. You can just drop this declaration.

Done.

https://codereview.chromium.org/1876123002/diff/140001/third_party/WebKit/Lay...
File
third_party/WebKit/LayoutTests/fast/css/getComputedStyle/getComputedStyle-padding-expected.html
(right):

https://codereview.chromium.org/1876123002/diff/140001/third_party/WebKit/Lay...
third_party/WebKit/LayoutTests/fast/css/getComputedStyle/getComputedStyle-padding-expected.html:4:
position: relative;
On 2016/05/12 09:34:03, mstensho wrote:
> This can be simplified. It's just a ref. A simple black 8em * 4em float
followed
> by "PASS" should do, right?

Done.

https://codereview.chromium.org/1876123002/diff/140001/third_party/WebKit/Lay...
File
third_party/WebKit/LayoutTests/fast/css/getComputedStyle/getComputedStyle-padding.html
(right):

https://codereview.chromium.org/1876123002/diff/140001/third_party/WebKit/Lay...
third_party/WebKit/LayoutTests/fast/css/getComputedStyle/getComputedStyle-padding.html:1:
<!DOCTYPE html>
On 2016/05/12 09:34:03, mstensho wrote:
> The file name is misleading. This has nothing to do with getComputedStyle.

Done.

[mstensho (USE GERRIT), 2016-05-12 11:35:27]

lgtm.

One final request, though: Could you write something more specific on the first
line of the description? Rather than "return correct value", maybe "include
containing block padding"?

https://codereview.chromium.org/1876123002/diff/160001/third_party/WebKit/Sou...
File third_party/WebKit/Source/core/layout/LayoutTable.cpp (right):

https://codereview.chromium.org/1876123002/diff/160001/third_party/WebKit/Sou...
third_party/WebKit/Source/core/layout/LayoutTable.cpp:266: LayoutUnit
availableLogicalWidth = containingBlockLogicalWidthForContent();
Yay!

[Deokjin Kim, 2016-05-12 11:41:12]

Description was changed from

==========
Absolute positioned child with percent should return correct value
    
The padding box of the containing block is to be used for absolutely
positioned descendants. But this rule is not applied yet. This CL
fixes 2 issue.
1. getComputedStyle on absolute positioned child with percent-based
left has to use containing block which includes padding box.
2. Absolute positioned child with percent-based padding also has to
use containing block which includes padding box.
    
BUG=601030
==========

to

==========
Absolute positioned child with percent should include containing block padding
    
The padding box of the containing block is to be used for absolutely
positioned descendants. But this rule is not applied yet. This CL
fixes 2 issue.
1. getComputedStyle on absolute positioned child with percent-based
left has to use containing block which includes padding box.
2. Absolute positioned child with percent-based padding also has to
use containing block which includes padding box.
    
BUG=601030
==========

[Deokjin Kim, 2016-05-12 11:41:45]

The CQ bit was checked by deokjin81.kim@samsung.com

[Deokjin Kim, 2016-05-12 11:41:46]

The patchset sent to the CQ was uploaded after l-g-t-m from mstensho@opera.com
Link to the patchset: https://codereview.chromium.org/1876123002/#ps180001
(title: "Modify commit message")

[commit-bot: I haz the power, 2016-05-12 11:41:52]

CQ is trying da patch. Follow status at
 https://chromium-cq-status.appspot.com/patch-status/1876123002/180001
View timeline at
 https://chromium-cq-status.appspot.com/patch-timeline/1876123002/180001

[commit-bot: I haz the power, 2016-05-12 15:52:06]

The CQ bit was unchecked by commit-bot@chromium.org

[commit-bot: I haz the power, 2016-05-12 15:52:08]

Try jobs failed on following builders:
  win_chromium_rel_ng on tryserver.chromium.win (JOB_FAILED,
http://build.chromium.org/p/tryserver.chromium.win/builders/win_chromium_rel_...)

[Deokjin Kim, 2016-05-12 20:22:46]

The CQ bit was checked by deokjin81.kim@samsung.com

[commit-bot: I haz the power, 2016-05-12 20:23:16]

CQ is trying da patch. Follow status at
 https://chromium-cq-status.appspot.com/patch-status/1876123002/180001
View timeline at
 https://chromium-cq-status.appspot.com/patch-timeline/1876123002/180001

[commit-bot: I haz the power, 2016-05-12 21:24:16]

Description was changed from

==========
Absolute positioned child with percent should include containing block padding
    
The padding box of the containing block is to be used for absolutely
positioned descendants. But this rule is not applied yet. This CL
fixes 2 issue.
1. getComputedStyle on absolute positioned child with percent-based
left has to use containing block which includes padding box.
2. Absolute positioned child with percent-based padding also has to
use containing block which includes padding box.
    
BUG=601030
==========

to

==========
Absolute positioned child with percent should include containing block padding
    
The padding box of the containing block is to be used for absolutely
positioned descendants. But this rule is not applied yet. This CL
fixes 2 issue.
1. getComputedStyle on absolute positioned child with percent-based
left has to use containing block which includes padding box.
2. Absolute positioned child with percent-based padding also has to
use containing block which includes padding box.
    
BUG=601030
==========

[commit-bot: I haz the power, 2016-05-12 21:24:18]

Committed patchset #10 (id:180001)

[commit-bot: I haz the power, 2016-05-12 21:26:03]

Description was changed from

==========
Absolute positioned child with percent should include containing block padding
    
The padding box of the containing block is to be used for absolutely
positioned descendants. But this rule is not applied yet. This CL
fixes 2 issue.
1. getComputedStyle on absolute positioned child with percent-based
left has to use containing block which includes padding box.
2. Absolute positioned child with percent-based padding also has to
use containing block which includes padding box.
    
BUG=601030
==========

to

==========
Absolute positioned child with percent should include containing block padding

The padding box of the containing block is to be used for absolutely
positioned descendants. But this rule is not applied yet. This CL
fixes 2 issue.
1. getComputedStyle on absolute positioned child with percent-based
left has to use containing block which includes padding box.
2. Absolute positioned child with percent-based padding also has to
use containing block which includes padding box.

BUG=601030

Committed: https://crrev.com/9908f45b70b65fc242e050d33c67294fe870a1cb
Cr-Commit-Position: refs/heads/master@{#393358}
==========

[commit-bot: I haz the power, 2016-05-12 21:26:06]

Patchset 10 (id:??) landed as
https://crrev.com/9908f45b70b65fc242e050d33c67294fe870a1cb
Cr-Commit-Position: refs/heads/master@{#393358}