Don't composite layers with an invisible frameview.

Don't composite layers with an invisible FrameView.

Required setting parent/self visible for the FrameView associated
with a WebPagePopupImpl. Previously these defaulted to invisible.

BUG=569643
Committed: https://crrev.com/510e13d1579b8fb895673358ac1a6594fbcadfe3
Cr-Commit-Position: refs/heads/master@{#372109}

[wkorman, 2016-01-21 22:37:34]

Description was changed from

==========
Don't composite layers with an invisible frameview.

Also required setting parent/self visible by default for the FrameView
associated with a WebPagePopupImpl, where previously these defaulted to
invisible.

BUG=569643
==========

to

==========
Don't composite layers with an invisible FrameView.

Required setting parent/self visible for the FrameView associated
with a WebPagePopupImpl. Previously these defaulted to invisible.

BUG=569643
==========

[wkorman, 2016-01-21 22:38:06]

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

[commit-bot: I haz the power, 2016-01-21 22:40:03]

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

[wkorman, 2016-01-21 22:43:41]

wkorman@chromium.org changed reviewers:
+ chrishtr@chromium.org

[wkorman, 2016-01-21 22:43:42]

compositing/iframes/invisible-nested-iframe-show.html fails locally with new
text expectations that omit the frame. I'm looking into this.

[chrishtr, 2016-01-21 22:49:18]

https://codereview.chromium.org/1616183002/diff/20001/third_party/WebKit/Layo...
File third_party/WebKit/LayoutTests/compositing/composited-iframe-hidden.html
(right):

https://codereview.chromium.org/1616183002/diff/20001/third_party/WebKit/Layo...
third_party/WebKit/LayoutTests/compositing/composited-iframe-hidden.html:33:
popup.click();
Instead of going through onclick, just set its style directly by calling
hideDialog() or inlining
the style here.

https://codereview.chromium.org/1616183002/diff/20001/third_party/WebKit/Layo...
File
third_party/WebKit/LayoutTests/compositing/resources/composited-iframe-hidden-2.html
(right):

https://codereview.chromium.org/1616183002/diff/20001/third_party/WebKit/Layo...
third_party/WebKit/LayoutTests/compositing/resources/composited-iframe-hidden-2.html:9:
animation: shineSmall 4s steps(6) infinite
Instead of an animated image, how about an infinitely rotating div square?

https://codereview.chromium.org/1616183002/diff/20001/third_party/WebKit/Sour...
File third_party/WebKit/Source/core/layout/compositing/PaintLayerCompositor.cpp
(right):

https://codereview.chromium.org/1616183002/diff/20001/third_party/WebKit/Sour...
third_party/WebKit/Source/core/layout/compositing/PaintLayerCompositor.cpp:771:
FrameView* frameView = layoutObject->frameView();
Just layer->layoutObject()->frameView() is ok.

https://codereview.chromium.org/1616183002/diff/20001/third_party/WebKit/Sour...
third_party/WebKit/Source/core/layout/compositing/PaintLayerCompositor.cpp:773:
return false;
Add a comment explaining this situation. e.g.:

Elements within an invisible frame need not be composited, because they are not
drawn.

[commit-bot: I haz the power, 2016-01-21 23:27:50]

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

[commit-bot: I haz the power, 2016-01-21 23:27:51]

Dry run: Try jobs failed on following builders:
  linux_chromium_asan_rel_ng on tryserver.chromium.linux (JOB_FAILED,
http://build.chromium.org/p/tryserver.chromium.linux/builders/linux_chromium_...)
  mac_chromium_rel_ng on tryserver.chromium.mac (JOB_FAILED,
http://build.chromium.org/p/tryserver.chromium.mac/builders/mac_chromium_rel_...)

[wkorman, 2016-01-22 00:19:56]

Also am still looking into test failures from CQ dry run.

https://codereview.chromium.org/1616183002/diff/20001/third_party/WebKit/Layo...
File third_party/WebKit/LayoutTests/compositing/composited-iframe-hidden.html
(right):

https://codereview.chromium.org/1616183002/diff/20001/third_party/WebKit/Layo...
third_party/WebKit/LayoutTests/compositing/composited-iframe-hidden.html:33:
popup.click();
On 2016/01/21 at 22:49:18, chrishtr wrote:
> Instead of going through onclick, just set its style directly by calling
hideDialog() or inlining
> the style here.

Done.

https://codereview.chromium.org/1616183002/diff/20001/third_party/WebKit/Layo...
File
third_party/WebKit/LayoutTests/compositing/resources/composited-iframe-hidden-2.html
(right):

https://codereview.chromium.org/1616183002/diff/20001/third_party/WebKit/Layo...
third_party/WebKit/LayoutTests/compositing/resources/composited-iframe-hidden-2.html:9:
animation: shineSmall 4s steps(6) infinite
On 2016/01/21 at 22:49:18, chrishtr wrote:
> Instead of an animated image, how about an infinitely rotating div square?

Assert failure does not repro with a rotating square. There seems to be
something about having a background image. I will investigate further.

https://codereview.chromium.org/1616183002/diff/20001/third_party/WebKit/Sour...
File third_party/WebKit/Source/core/layout/compositing/PaintLayerCompositor.cpp
(right):

https://codereview.chromium.org/1616183002/diff/20001/third_party/WebKit/Sour...
third_party/WebKit/Source/core/layout/compositing/PaintLayerCompositor.cpp:771:
FrameView* frameView = layoutObject->frameView();
On 2016/01/21 at 22:49:18, chrishtr wrote:
> Just layer->layoutObject()->frameView() is ok.

Done. I pulled layoutObject into a local variable to shorten two references in
line 775 and 776, so I've restored those as well.

https://codereview.chromium.org/1616183002/diff/20001/third_party/WebKit/Sour...
third_party/WebKit/Source/core/layout/compositing/PaintLayerCompositor.cpp:773:
return false;
On 2016/01/21 at 22:49:18, chrishtr wrote:
> Add a comment explaining this situation. e.g.:
> 
> Elements within an invisible frame need not be composited, because they are
not drawn.

Done.

[wkorman, 2016-01-22 22:35:38]

On 2016/01/22 at 00:19:56, wkorman wrote:
> Also am still looking into test failures from CQ dry run.

Brief update:

- current patch has explicit fixes to set parent/self visibility for test cases.
I'd like to explore in subsequent patch just changing the default visibility to
true which would simplify code. I don't know enough yet about the concept of
parent/self visibility and so ramifications of making this change more broadly.
Fixing immediate issue first with this approach seems worthwhile in interim.

- continuing to investigate one failing layout test:

compositing/iframes/invisible-nested-iframe-show.html

One current theory is that it looks like, before the test shows the hidden
iframes, we run through compositing layer assignment and decide not to composite
the iframe's layers because their containing frameview isn't visible. Then, when
we show the subtree by removing 'display: none' on their containing div's style,
we do not re-composite. It could be that we want to add a call to
setNeedsCompositingUpdate() somewhere. However it's surprising to me that we
still render the page correctly even though we don't re-do the compositing. I am
still fairly new to the compositing layer assignment logic and ramifications of
what happens if we do vs don't composite.

[wkorman, 2016-01-23 02:00:10]

Note without patch applied we break in CompositingReasonFinder with
CompositingReasonIFrame, but with patch we never do:

% b CompositingReasonFinder.cpp:165 if
layoutObject->additionalCompositingReasons() == 16

Proceeding with investigation to understand why the difference. I also found
there's already logic in PaintLayer::styleChanged() around updating compositing,
so re: my prior note I don't think it's that we need to call
setNeedsCompositingUpdate().

[wkorman, 2016-01-23 05:19:09]

On 2016/01/23 at 02:00:10, wkorman wrote:
> Note without patch applied we break in CompositingReasonFinder with
CompositingReasonIFrame, but with patch we never do:
> 
> % b CompositingReasonFinder.cpp:165 if
layoutObject->additionalCompositingReasons() == 16
> 
> Proceeding with investigation to understand why the difference. I also found
there's already logic in PaintLayer::styleChanged() around updating compositing,
so re: my prior note I don't think it's that we need to call
setNeedsCompositingUpdate().

Work continues, noting findings:

With the patch applied LayoutPart::requiresAcceleratedCompositing() returns
false in all cases due to view->usesCompositing() always returning false. Thus
when we update compositing requirements we never conclude the iframes are in
need of compositing (requiresAcceleratedCompositing() is used in calculating
directReasons() for compositing in the PaintLayerCompositor and
CompositingRequirementsUpdater).

On initial page load with the iframe hidden and we don't composite those paint
layers within an invisible frame view, this incorrectly leads to their never
subsequently being composited.

[chrishtr, 2016-01-23 05:24:28]

On 2016/01/23 at 05:19:09, wkorman wrote:
> On 2016/01/23 at 02:00:10, wkorman wrote:
> > Note without patch applied we break in CompositingReasonFinder with
CompositingReasonIFrame, but with patch we never do:
> > 
> > % b CompositingReasonFinder.cpp:165 if
layoutObject->additionalCompositingReasons() == 16
> > 
> > Proceeding with investigation to understand why the difference. I also found
there's already logic in PaintLayer::styleChanged() around updating compositing,
so re: my prior note I don't think it's that we need to call
setNeedsCompositingUpdate().
> 
> Work continues, noting findings:
> 
> With the patch applied LayoutPart::requiresAcceleratedCompositing() returns
false in all cases due to view->usesCompositing() always returning false.

Why does it always return false? If the frame becomes visible, then the
conditional you added to line 773 of PaintLayerCompositor.cpp should no longer
apply.

 Thus when we update compositing requirements we never conclude the iframes are
in need of compositing (requiresAcceleratedCompositing() is used in calculating
directReasons() for compositing in the PaintLayerCompositor and
CompositingRequirementsUpdater).
> 
> On initial page load with the iframe hidden and we don't composite those paint
layers within an invisible frame view, this incorrectly leads to their never
subsequently being composited.

[wkorman, 2016-01-23 05:33:46]

On 2016/01/23 at 05:24:28, chrishtr wrote:
> On 2016/01/23 at 05:19:09, wkorman wrote:
> > On 2016/01/23 at 02:00:10, wkorman wrote:
> > > Note without patch applied we break in CompositingReasonFinder with
CompositingReasonIFrame, but with patch we never do:
> > > 
> > > % b CompositingReasonFinder.cpp:165 if
layoutObject->additionalCompositingReasons() == 16
> > > 
> > > Proceeding with investigation to understand why the difference. I also
found there's already logic in PaintLayer::styleChanged() around updating
compositing, so re: my prior note I don't think it's that we need to call
setNeedsCompositingUpdate().
> > 
> > Work continues, noting findings:
> > 
> > With the patch applied LayoutPart::requiresAcceleratedCompositing() returns
false in all cases due to view->usesCompositing() always returning false.
> 
> Why does it always return false? If the frame becomes visible, then the
conditional you added to line 773 of PaintLayerCompositor.cpp should no longer
apply.

For an IFrame the reason to composite looks to come from directReasons():

https://code.google.com/p/chromium/codesearch#chromium/src/third_party/WebKit...

[chrishtr, 2016-01-23 05:47:03]

On 2016/01/23 at 05:33:46, wkorman wrote:
> On 2016/01/23 at 05:24:28, chrishtr wrote:
> > On 2016/01/23 at 05:19:09, wkorman wrote:
> > > On 2016/01/23 at 02:00:10, wkorman wrote:
> > > > Note without patch applied we break in CompositingReasonFinder with
CompositingReasonIFrame, but with patch we never do:
> > > > 
> > > > % b CompositingReasonFinder.cpp:165 if
layoutObject->additionalCompositingReasons() == 16
> > > > 
> > > > Proceeding with investigation to understand why the difference. I also
found there's already logic in PaintLayer::styleChanged() around updating
compositing, so re: my prior note I don't think it's that we need to call
setNeedsCompositingUpdate().
> > > 
> > > Work continues, noting findings:
> > > 
> > > With the patch applied LayoutPart::requiresAcceleratedCompositing()
returns false in all cases due to view->usesCompositing() always returning
false.
> > 
> > Why does it always return false? If the frame becomes visible, then the
conditional you added to line 773 of PaintLayerCompositor.cpp should no longer
apply.
> 
> For an IFrame the reason to composite looks to come from directReasons():
> 
>
https://code.google.com/p/chromium/codesearch#chromium/src/third_party/WebKit...

Yes, but why is view->usesCompositing() always returning false? I would expect
it to become true once the view becomes visible.

[wkorman, 2016-01-25 20:38:58]

On 2016/01/23 at 05:47:03, chrishtr wrote:
> Yes, but why is view->usesCompositing() always returning false? I would expect
it to become true once the view becomes visible.

It looks like we never call PaintLayerCompositor::setCompositingModeEnabled() as
part of or after calling FrameView::show(), thus m_compositing is false with the
patch because it's false when initially considered (due to invisible frame view)
and then we never revisit. I am tracing all possible call sites and reading
involved code to understand when/on what basis it is supposed to be called.

[chrishtr, 2016-01-26 18:18:34]

On 2016/01/25 at 20:38:58, wkorman wrote:
> On 2016/01/23 at 05:47:03, chrishtr wrote:
> > Yes, but why is view->usesCompositing() always returning false? I would
expect it to become true once the view becomes visible.
> 
> It looks like we never call PaintLayerCompositor::setCompositingModeEnabled()
as part of or after calling FrameView::show(), thus m_compositing is false with
the patch because it's false when initially considered (due to invisible frame
view) and then we never revisit. I am tracing all possible call sites and
reading involved code to understand when/on what basis it is supposed to be
called.

That's strange though. I assume that in general we don't have a bug with making
frames invisible and then re-compositing them after. Compositing mode should be
re-enabled here:

https://code.google.com/p/chromium/codesearch#chromium/src/third_party/WebKit...

once it is visible.

[wkorman, 2016-01-28 00:25:24]

On 2016/01/26 at 18:18:34, chrishtr wrote:
> On 2016/01/25 at 20:38:58, wkorman wrote:
> > On 2016/01/23 at 05:47:03, chrishtr wrote:
> > > Yes, but why is view->usesCompositing() always returning false? I would
expect it to become true once the view becomes visible.
> > 
> > It looks like we never call
PaintLayerCompositor::setCompositingModeEnabled() as part of or after calling
FrameView::show(), thus m_compositing is false with the patch because it's false
when initially considered (due to invisible frame view) and then we never
revisit. I am tracing all possible call sites and reading involved code to
understand when/on what basis it is supposed to be called.
> 
> That's strange though. I assume that in general we don't have a bug with
making frames invisible and then re-compositing them after. Compositing mode
should be re-enabled here:
> 
>
https://code.google.com/p/chromium/codesearch#chromium/src/third_party/WebKit...
> 
> once it is visible.

For those who may follow along now or in the future, after much poking and
prodding it was determined that a compositing update may be needed when frame
view visibility changes and so have added needed bit to
FrameView::setParentVisible.

This fixes the text expectations for
compositing/iframes/invisible-nested-iframe-show.html to match previous. It also
breaks the text expectations for
compositing/iframes/invisible-nested-iframe-hide.html though I will
preliminarily claim that may be newly-correct behavior with the potential for
some modicum of performance/memory improvement. I'm running a linux_blink_rel
try job with this latest patch so that I can point to the text diff, and am
double-checking it locally to make sure nothing untoward is afoot.

Local layout tests also showed a broken popup test image for
http/tests/webfont/popup-menu-load-webfont-after-open.html which may need to be
investigated if it happens on the bot as well.

[chrishtr, 2016-01-28 00:32:31]

https://codereview.chromium.org/1616183002/diff/130001/third_party/WebKit/Lay...
File
third_party/WebKit/LayoutTests/compositing/composited-iframe-hidden-expected.html
(right):

https://codereview.chromium.org/1616183002/diff/130001/third_party/WebKit/Lay...
third_party/WebKit/LayoutTests/compositing/composited-iframe-hidden-expected.html:2:
<div style="visibility: hidden;"><iframe></iframe></div>
Just <div></div should work?

https://codereview.chromium.org/1616183002/diff/130001/third_party/WebKit/Lay...
File
third_party/WebKit/LayoutTests/compositing/resources/composited-iframe-hidden-2.html
(right):

https://codereview.chromium.org/1616183002/diff/130001/third_party/WebKit/Lay...
third_party/WebKit/LayoutTests/compositing/resources/composited-iframe-hidden-2.html:1:
<!DOCTYPE html>
Rename file to composited-iframe-hidden-subframe.html

https://codereview.chromium.org/1616183002/diff/130001/third_party/WebKit/Lay...
third_party/WebKit/LayoutTests/compositing/resources/composited-iframe-hidden-2.html:7:
background: url("./shine.png") no-repeat 0 0 transparent;
Try to use an existing infinitely animated gif. There is a red-green blinking
one somewhere
IIRC.

https://codereview.chromium.org/1616183002/diff/130001/third_party/WebKit/Sou...
File third_party/WebKit/Source/core/frame/FrameView.cpp (right):

https://codereview.chromium.org/1616183002/diff/130001/third_party/WebKit/Sou...
third_party/WebKit/Source/core/frame/FrameView.cpp:3823: for (const auto& child
: m_children) {
Remove curlies.

https://codereview.chromium.org/1616183002/diff/130001/third_party/WebKit/Sou...
File
third_party/WebKit/Source/core/layout/compositing/CompositingLayerAssigner.cpp
(right):

https://codereview.chromium.org/1616183002/diff/130001/third_party/WebKit/Sou...
third_party/WebKit/Source/core/layout/compositing/CompositingLayerAssigner.cpp:29:
#include "core/frame/FrameView.h"
Remove

https://codereview.chromium.org/1616183002/diff/130001/third_party/WebKit/Sou...
File third_party/WebKit/Source/core/layout/compositing/PaintLayerCompositor.cpp
(right):

https://codereview.chromium.org/1616183002/diff/130001/third_party/WebKit/Sou...
third_party/WebKit/Source/core/layout/compositing/PaintLayerCompositor.cpp:771:
// Elements within an invisible frame need not be composited because they are
not drawn.
s/need/must/

[wkorman, 2016-01-28 00:55:22]

https://codereview.chromium.org/1616183002/diff/130001/third_party/WebKit/Lay...
File
third_party/WebKit/LayoutTests/compositing/composited-iframe-hidden-expected.html
(right):

https://codereview.chromium.org/1616183002/diff/130001/third_party/WebKit/Lay...
third_party/WebKit/LayoutTests/compositing/composited-iframe-hidden-expected.html:2:
<div style="visibility: hidden;"><iframe></iframe></div>
On 2016/01/28 at 00:32:31, chrishtr wrote:
> Just <div></div should work?

Since the hidden iframe still occupies space, we need to account for that space
in this expectation somehow. This seemed like the most maintainable approach
since it emulates the source document re: using an actual iframe element.

We could alternately see what the size of the default-styled iframe is (150px
high + 4px for border) and apply that to the padding/margin-top of the <p> below
but then that's fragile to iframe changes in future. Am happy to do that instead
if you think preferred.

https://codereview.chromium.org/1616183002/diff/130001/third_party/WebKit/Lay...
File
third_party/WebKit/LayoutTests/compositing/resources/composited-iframe-hidden-2.html
(right):

https://codereview.chromium.org/1616183002/diff/130001/third_party/WebKit/Lay...
third_party/WebKit/LayoutTests/compositing/resources/composited-iframe-hidden-2.html:1:
<!DOCTYPE html>
On 2016/01/28 at 00:32:31, chrishtr wrote:
> Rename file to composited-iframe-hidden-subframe.html

Done.

https://codereview.chromium.org/1616183002/diff/130001/third_party/WebKit/Lay...
third_party/WebKit/LayoutTests/compositing/resources/composited-iframe-hidden-2.html:7:
background: url("./shine.png") no-repeat 0 0 transparent;
On 2016/01/28 at 00:32:31, chrishtr wrote:
> Try to use an existing infinitely animated gif. There is a red-green blinking
one somewhere
> IIRC.

Done. Took a 100x100 blue from another existing test. Doesn't need to be an
animated image, and was able to remove the background-color property as well.

https://codereview.chromium.org/1616183002/diff/130001/third_party/WebKit/Sou...
File third_party/WebKit/Source/core/frame/FrameView.cpp (right):

https://codereview.chromium.org/1616183002/diff/130001/third_party/WebKit/Sou...
third_party/WebKit/Source/core/frame/FrameView.cpp:3823: for (const auto& child
: m_children) {
On 2016/01/28 at 00:32:31, chrishtr wrote:
> Remove curlies.

Done.

https://codereview.chromium.org/1616183002/diff/130001/third_party/WebKit/Sou...
File
third_party/WebKit/Source/core/layout/compositing/CompositingLayerAssigner.cpp
(right):

https://codereview.chromium.org/1616183002/diff/130001/third_party/WebKit/Sou...
third_party/WebKit/Source/core/layout/compositing/CompositingLayerAssigner.cpp:29:
#include "core/frame/FrameView.h"
On 2016/01/28 at 00:32:31, chrishtr wrote:
> Remove

Done.

https://codereview.chromium.org/1616183002/diff/130001/third_party/WebKit/Sou...
File third_party/WebKit/Source/core/layout/compositing/PaintLayerCompositor.cpp
(right):

https://codereview.chromium.org/1616183002/diff/130001/third_party/WebKit/Sou...
third_party/WebKit/Source/core/layout/compositing/PaintLayerCompositor.cpp:771:
// Elements within an invisible frame need not be composited because they are
not drawn.
On 2016/01/28 at 00:32:31, chrishtr wrote:
> s/need/must/

Done.

[wkorman, 2016-01-28 00:56:30]

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

[commit-bot: I haz the power, 2016-01-28 00:56:59]

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

[chrishtr, 2016-01-28 01:07:02]

lgtm

[commit-bot: I haz the power, 2016-01-28 02:37:50]

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

[commit-bot: I haz the power, 2016-01-28 02:37:50]

Dry run: Try jobs failed on following builders:
  mac_chromium_rel_ng on tryserver.chromium.mac (JOB_FAILED,
http://build.chromium.org/p/tryserver.chromium.mac/builders/mac_chromium_rel_...)

[wkorman, 2016-01-28 07:58:00]

The CQ bit was checked by wkorman@chromium.org

[wkorman, 2016-01-28 07:58:00]

The patchset sent to the CQ was uploaded after l-g-t-m from
chrishtr@chromium.org
Link to the patchset: https://codereview.chromium.org/1616183002/#ps190001
(title: "Add test expectation.")

[commit-bot: I haz the power, 2016-01-28 07:58:41]

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

[commit-bot: I haz the power, 2016-01-28 09:15:48]

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

[commit-bot: I haz the power, 2016-01-28 09:15:50]

Try jobs failed on following builders:
  mac_chromium_rel_ng on tryserver.chromium.mac (JOB_FAILED,
http://build.chromium.org/p/tryserver.chromium.mac/builders/mac_chromium_rel_...)

[wkorman, 2016-01-28 16:24:25]

The CQ bit was checked by wkorman@chromium.org

[commit-bot: I haz the power, 2016-01-28 16:25:17]

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

[commit-bot: I haz the power, 2016-01-28 17:01:15]

Committed patchset #11 (id:190001)

[commit-bot: I haz the power, 2016-01-28 17:02:03]

Description was changed from

==========
Don't composite layers with an invisible FrameView.

Required setting parent/self visible for the FrameView associated
with a WebPagePopupImpl. Previously these defaulted to invisible.

BUG=569643
==========

to

==========
Don't composite layers with an invisible FrameView.

Required setting parent/self visible for the FrameView associated
with a WebPagePopupImpl. Previously these defaulted to invisible.

BUG=569643

Committed: https://crrev.com/510e13d1579b8fb895673358ac1a6594fbcadfe3
Cr-Commit-Position: refs/heads/master@{#372109}
==========

[commit-bot: I haz the power, 2016-01-28 17:02:04]

Patchset 11 (id:??) landed as
https://crrev.com/510e13d1579b8fb895673358ac1a6594fbcadfe3
Cr-Commit-Position: refs/heads/master@{#372109}