Include the whole outline into visual overflow

Include the whole outline into visual overflow

This is another preparation CL for combining outline and focus ring
paths (https://codereview.chromium.org/1224933002/).

Not including the whole outline into visual overflow caused
incorrect layout and painting of outlines when the element having
outline has clipping or is composited because the overflow doesn't
cover the whole outline.

Not including outlines of block continuations into visual overflow
required us to
- propagate outline style to block continuations on style change;
- paint outlines for block continuations separately, causing
  unconnected or duplicated outline edges.
Both of the above caused complex code.

With this CL, we always include the whole outline into visual
overflow of the object having outline style.
- For LayoutBoxes, combine code paths about overflow for focus ring
  and outline;
- For LayoutBlockFlows, we need to include the visual overflow of
  descendant LayoutInlines having continuation and outline. Let the
  containing LayoutBlockFlow record LayoutInlines with outline and
  continuation, and include the outline rects of continuations
  into visual overflow of the block.

(FYI, cases that we already included outlines into visual overflow:
 - LayoutBlockFlow containing descendant LayoutInlines having outline
   but not continuation: we already included such outlines in visual
   overflow of InlineFlowBoxes and in turn into the LayoutBlockFlow;
 - LayoutInlines having outline: previously we include outlines by
   calling rectWithOutlineForPaintInvalidation(); with this CL we
   call addOutlineRects().)

This CL will have real effect with
https://codereview.chromium.org/1224933002/.

BUG=506669
Committed: https://src.chromium.org/viewvc/blink?view=rev&revision=201418

[Xianzhu, 2015-08-06 18:12:45]

wangxianzhu@chromium.org changed reviewers:
+ chrishtr@chromium.org, leviw@chromium.org

[Xianzhu, 2015-08-06 18:12:46]

Ptal.

Added some inline notes for reviewers.

https://codereview.chromium.org/1278543002/diff/20001/Source/core/layout/Layo...
File Source/core/layout/LayoutBlockFlowLine.cpp (right):

https://codereview.chromium.org/1278543002/diff/20001/Source/core/layout/Layo...
Source/core/layout/LayoutBlockFlowLine.cpp:56: static
InlinesWithOutlineAndContinuationMap* gInlinesWithOutlineAndContinuationMap =
nullptr;
Note: This map will replace the continuationOutlineTable in LayoutBlock.h in
https://codereview.chromium.org/1224933002/. For now that map is kept because
the paint code is still using it.

https://codereview.chromium.org/1278543002/diff/20001/Source/core/layout/Layo...
File Source/core/layout/LayoutBoxModelObject.cpp (right):

https://codereview.chromium.org/1278543002/diff/20001/Source/core/layout/Layo...
Source/core/layout/LayoutBoxModelObject.cpp:417: if
(descendant.isLayoutInline()) {
This is a refactor of the original LayoutInline::addOutlineRects() in which we
used a tricky condition to prevent duplicated rects for line boxes. With this
change we make the condition explicit.

https://codereview.chromium.org/1278543002/diff/80001/LayoutTests/platform/li...
File LayoutTests/platform/linux/fast/repaint/outline-continuations-expected.txt
(left):

https://codereview.chromium.org/1278543002/diff/80001/LayoutTests/platform/li...
LayoutTests/platform/linux/fast/repaint/outline-continuations-expected.txt:17:
[14, 148, 208, 46],
This was because outline width was added into visual overflow twice in some
cases during rectWithOutlineForPaintInvalidation().

https://codereview.chromium.org/1278543002/diff/100001/LayoutTests/fast/spati...
File LayoutTests/fast/spatial-navigation/snav-clipped-overflowed-content.html
(right):

https://codereview.chromium.org/1278543002/diff/100001/LayoutTests/fast/spati...
LayoutTests/fast/spatial-navigation/snav-clipped-overflowed-content.html:78: <a
id="1" href="a"><img src="resources/green.png" width=30px height=35px></a>
This change is because this CL fixed an original bug of
LayoutInline::clippedOverflowRect which applied outline width twice. The changed
result caused different focus navigation behavior. Change the test to make it
produce the expected result.

[chrishtr, 2015-08-07 04:52:11]

https://codereview.chromium.org/1278543002/diff/140001/Source/core/layout/Lay...
File Source/core/layout/LayoutBlockFlowLine.cpp (right):

https://codereview.chromium.org/1278543002/diff/140001/Source/core/layout/Lay...
Source/core/layout/LayoutBlockFlowLine.cpp:56: static
InlinesWithOutlineAndContinuationMap* gInlinesWithOutlineAndContinuationMap =
nullptr;
Why do you need a global? Why can't it hang off the LayoutBlockFlow?

https://codereview.chromium.org/1278543002/diff/140001/Source/core/layout/Lay...
File Source/core/layout/LayoutBoxModelObject.cpp (right):

https://codereview.chromium.org/1278543002/diff/140001/Source/core/layout/Lay...
Source/core/layout/LayoutBoxModelObject.cpp:419: return;
Can the refactor you referred to be made into its own patch?

[Xianzhu, 2015-08-07 16:25:37]

https://codereview.chromium.org/1278543002/diff/140001/Source/core/layout/Lay...
File Source/core/layout/LayoutBlockFlowLine.cpp (right):

https://codereview.chromium.org/1278543002/diff/140001/Source/core/layout/Lay...
Source/core/layout/LayoutBlockFlowLine.cpp:56: static
InlinesWithOutlineAndContinuationMap* gInlinesWithOutlineAndContinuationMap =
nullptr;
On 2015/08/07 04:52:10, chrishtr wrote:
> Why do you need a global?
> Why can't it hang off the LayoutBlockFlow?

That will increase the size of every LayoutBlockFlow by sizeof(HashMap) (24
bytes) or sizeof a pointer (if we use OwnPtr). Only a small part of
LayoutBlockFlows need the map. File-local global map seems a idiom to contain
rare data.

https://codereview.chromium.org/1278543002/diff/140001/Source/core/layout/Lay...
File Source/core/layout/LayoutBoxModelObject.cpp (right):

https://codereview.chromium.org/1278543002/diff/140001/Source/core/layout/Lay...
Source/core/layout/LayoutBoxModelObject.cpp:419: return;
On 2015/08/07 04:52:10, chrishtr wrote:
> Can the refactor you referred to be made into its own patch?

Done. Ptal: https://codereview.chromium.org/1280543005/

[leviw_travelin_and_unemployed, 2015-08-10 20:13:14]

https://codereview.chromium.org/1278543002/diff/160001/Source/core/layout/Lay...
File Source/core/layout/LayoutBlockFlowLine.cpp (right):

https://codereview.chromium.org/1278543002/diff/160001/Source/core/layout/Lay...
Source/core/layout/LayoutBlockFlowLine.cpp:1541:
removeInlinesWithOutlineAndContinuation();
It's a bit unfortunate that we incur a hash lookup for every BlockFlow layout if
we have a single inline with outline and continuation. It'd be nice if we had
data for how common this really ends up being (% of pages, and number of inlines
per page) to make a more informed decision about the memory tradeoff. I'm
generally surprised by the prevalence of continuations on the web, but I don't
have a feel for how prevalent this combo is.

[chrishtr, 2015-08-10 23:45:33]

https://codereview.chromium.org/1278543002/diff/160001/Source/core/layout/Lay...
File Source/core/layout/LayoutBlockFlowLine.cpp (right):

https://codereview.chromium.org/1278543002/diff/160001/Source/core/layout/Lay...
Source/core/layout/LayoutBlockFlowLine.cpp:1898:
flow->addOutlineRectsForContinuations(outlineRects, LayoutPoint());
Is this cache really so important for performance? I suggest you get rid of it
and use the code from 1588 inside of a loop over all children.

[Xianzhu, 2015-08-11 17:57:50]

https://codereview.chromium.org/1278543002/diff/160001/Source/core/layout/Lay...
File Source/core/layout/LayoutBlockFlowLine.cpp (right):

https://codereview.chromium.org/1278543002/diff/160001/Source/core/layout/Lay...
Source/core/layout/LayoutBlockFlowLine.cpp:1541:
removeInlinesWithOutlineAndContinuation();
On 2015/08/10 20:13:14, leviw wrote:
> It's a bit unfortunate that we incur a hash lookup for every BlockFlow layout
if
> we have a single inline with outline and continuation. It'd be nice if we had
> data for how common this really ends up being (% of pages, and number of
inlines
> per page) to make a more informed decision about the memory tradeoff. I'm
> generally surprised by the prevalence of continuations on the web, but I don't
> have a feel for how prevalent this combo is.

Ran top-10k web sites, 7986 of them succeeded, and none of them contains inline
with outline and continuation.

I think the reasons might be:
- Outlines of inlines are very broken at least in WebKit/blink, web developers
are likely to avoid them when they see the breakage;
- The feature might be also implemented differently on different browsers;
- The static test doesn't cover focus ring cases.

Because there might be more focus ring cases, I think we still should implement
the feature correctly. Because normally there is at most one focus ring in a
document, the map may normally have only one entry or empty/null in most cases,
and lookup of such a map should be super fast.

In addition, the map is equivalent to the existing continuationOutlineTable() in
LayoutBlock which will be removed in the next CL. We can't just reuse that map
because continuationOutlineTable() is populated and used during painting only
which conflicts with the usage of this CL (during layout). So eventually this CL
doesn't add a new map, but fixes the tricky relationship between layout and
paint.

https://codereview.chromium.org/1278543002/diff/160001/Source/core/layout/Lay...
Source/core/layout/LayoutBlockFlowLine.cpp:1898:
flow->addOutlineRectsForContinuations(outlineRects, LayoutPoint());
On 2015/08/10 23:45:33, chrishtr wrote:
> Is this cache really so important for performance? I suggest you get rid of it
> and use the code from 1588 inside of a loop over all children.

They are in different document stages. The code from 1588 is during layout, here
is during overflow recalc. We may have overflow recalc without layout, so we
need cache the result from earlier layout.

[chrishtr, 2015-08-13 20:04:14]

https://codereview.chromium.org/1278543002/diff/160001/Source/core/layout/Lay...
File Source/core/layout/LayoutBlockFlowLine.cpp (right):

https://codereview.chromium.org/1278543002/diff/160001/Source/core/layout/Lay...
Source/core/layout/LayoutBlockFlowLine.cpp:1898:
flow->addOutlineRectsForContinuations(outlineRects, LayoutPoint());
On 2015/08/11 at 17:57:50, Xianzhu wrote:
> On 2015/08/10 23:45:33, chrishtr wrote:
> > Is this cache really so important for performance? I suggest you get rid of
it
> > and use the code from 1588 inside of a loop over all children.
> 
> They are in different document stages. The code from 1588 is during layout,
here is during overflow recalc. We may have overflow recalc without layout, so
we need cache the result from earlier layout.

You're saying that the layout data necessary to loop over children adn check
their styles may not be available or up-to-date here?

All I was saying about 1588 is to copy the code from there.

[Xianzhu, 2015-08-13 20:26:00]

https://codereview.chromium.org/1278543002/diff/160001/Source/core/layout/Lay...
File Source/core/layout/LayoutBlockFlowLine.cpp (right):

https://codereview.chromium.org/1278543002/diff/160001/Source/core/layout/Lay...
Source/core/layout/LayoutBlockFlowLine.cpp:1898:
flow->addOutlineRectsForContinuations(outlineRects, LayoutPoint());
On 2015/08/13 20:04:13, chrishtr wrote:
> On 2015/08/11 at 17:57:50, Xianzhu wrote:
> > On 2015/08/10 23:45:33, chrishtr wrote:
> > > Is this cache really so important for performance? I suggest you get rid
of
> it
> > > and use the code from 1588 inside of a loop over all children.
> > 
> > They are in different document stages. The code from 1588 is during layout,
> here is during overflow recalc. We may have overflow recalc without layout, so
> we need cache the result from earlier layout.
> 
> You're saying that the layout data necessary to loop over children adn check
> their styles may not be available or up-to-date here?
> 
> All I was saying about 1588 is to copy the code from there.

I see. That would cause we always traverse the whole subtree during overflow
update even if there is no interesting inline descendant. However, I think I can
set a bit to indicate whether there is such descendant during layout, and
traverse here if the bit is set, to avoid the map. Will upload a new patch soon.

[chrishtr, 2015-08-27 17:46:00]

On 2015/08/13 at 20:26:00, wangxianzhu wrote:
>
https://codereview.chromium.org/1278543002/diff/160001/Source/core/layout/Lay...
> File Source/core/layout/LayoutBlockFlowLine.cpp (right):
> 
>
https://codereview.chromium.org/1278543002/diff/160001/Source/core/layout/Lay...
> Source/core/layout/LayoutBlockFlowLine.cpp:1898:
flow->addOutlineRectsForContinuations(outlineRects, LayoutPoint());
> On 2015/08/13 20:04:13, chrishtr wrote:
> > On 2015/08/11 at 17:57:50, Xianzhu wrote:
> > > On 2015/08/10 23:45:33, chrishtr wrote:
> > > > Is this cache really so important for performance? I suggest you get rid
of
> > it
> > > > and use the code from 1588 inside of a loop over all children.
> > > 
> > > They are in different document stages. The code from 1588 is during
layout,
> > here is during overflow recalc. We may have overflow recalc without layout,
so
> > we need cache the result from earlier layout.
> > 
> > You're saying that the layout data necessary to loop over children adn check
> > their styles may not be available or up-to-date here?
> > 
> > All I was saying about 1588 is to copy the code from there.
> 
> I see. That would cause we always traverse the whole subtree during overflow
update even if there is no interesting inline descendant. However, I think I can
set a bit to indicate whether there is such descendant during layout, and
traverse here if the bit is set, to avoid the map. Will upload a new patch soon.

Ping? I was waiting for the new patchset with the bits..

[Xianzhu, 2015-08-27 17:53:49]

On 2015/08/27 17:46:00, chrishtr wrote:
> On 2015/08/13 at 20:26:00, wangxianzhu wrote:
> >
>
https://codereview.chromium.org/1278543002/diff/160001/Source/core/layout/Lay...
> > File Source/core/layout/LayoutBlockFlowLine.cpp (right):
> > 
> >
>
https://codereview.chromium.org/1278543002/diff/160001/Source/core/layout/Lay...
> > Source/core/layout/LayoutBlockFlowLine.cpp:1898:
> flow->addOutlineRectsForContinuations(outlineRects, LayoutPoint());
> > On 2015/08/13 20:04:13, chrishtr wrote:
> > > On 2015/08/11 at 17:57:50, Xianzhu wrote:
> > > > On 2015/08/10 23:45:33, chrishtr wrote:
> > > > > Is this cache really so important for performance? I suggest you get
rid
> of
> > > it
> > > > > and use the code from 1588 inside of a loop over all children.
> > > > 
> > > > They are in different document stages. The code from 1588 is during
> layout,
> > > here is during overflow recalc. We may have overflow recalc without
layout,
> so
> > > we need cache the result from earlier layout.
> > > 
> > > You're saying that the layout data necessary to loop over children adn
check
> > > their styles may not be available or up-to-date here?
> > > 
> > > All I was saying about 1588 is to copy the code from there.
> > 
> > I see. That would cause we always traverse the whole subtree during overflow
> update even if there is no interesting inline descendant. However, I think I
can
> set a bit to indicate whether there is such descendant during layout, and
> traverse here if the bit is set, to avoid the map. Will upload a new patch
soon.
> 
> Ping? I was waiting for the new patchset with the bits..

Sorry I forgot to send a message after uploading the last patchset. It avoids
the global map using a bit to indicate if there is any descendant inline with
outline and continuation. If the bit is set, we traverse the inlines to include
outlines into visual overflow.

[chrishtr, 2015-08-27 18:20:59]

https://codereview.chromium.org/1278543002/diff/180001/Source/core/layout/Lay...
File Source/core/layout/LayoutBlockFlowLine.cpp (right):

https://codereview.chromium.org/1278543002/diff/180001/Source/core/layout/Lay...
Source/core/layout/LayoutBlockFlowLine.cpp:1531:
setContainsInlineWithOutlineAndContinuation(false);
If the DOM changes to remove all inline children, will this line sometimes not
execute? I think not, looking at line 372 in LayoutBlockFlow.cpp. Instead, move
this line into layoutBlockFlow()?

https://codereview.chromium.org/1278543002/diff/180001/Source/core/layout/Lay...
Source/core/layout/LayoutBlockFlowLine.cpp:1578: if
(!containsInlineWithOutlineAndContinuation() &&
isInlineWithOutlineAndContinuation(*o))
What's the point of checking for !containsInlineWithOutlineAndContinuation()?

https://codereview.chromium.org/1278543002/diff/180001/Source/core/layout/Lay...
File Source/core/layout/LayoutInline.cpp (right):

https://codereview.chromium.org/1278543002/diff/180001/Source/core/layout/Lay...
Source/core/layout/LayoutInline.cpp:1375: 
spurious

[Xianzhu, 2015-08-27 19:23:13]

https://codereview.chromium.org/1278543002/diff/180001/Source/core/layout/Lay...
File Source/core/layout/LayoutBlockFlowLine.cpp (right):

https://codereview.chromium.org/1278543002/diff/180001/Source/core/layout/Lay...
Source/core/layout/LayoutBlockFlowLine.cpp:1531:
setContainsInlineWithOutlineAndContinuation(false);
On 2015/08/27 18:20:59, chrishtr wrote:
> If the DOM changes to remove all inline children, will this line sometimes not
> execute? I think not, looking at line 372 in LayoutBlockFlow.cpp. Instead,
move
> this line into layoutBlockFlow()?

Nice catch. Done.

https://codereview.chromium.org/1278543002/diff/180001/Source/core/layout/Lay...
Source/core/layout/LayoutBlockFlowLine.cpp:1578: if
(!containsInlineWithOutlineAndContinuation() &&
isInlineWithOutlineAndContinuation(*o))
On 2015/08/27 18:20:59, chrishtr wrote:
> What's the point of checking for !containsInlineWithOutlineAndContinuation()?

Was to avoid the cost of isInlineWithOutlineAndContinuation() once the flag is
set. Seems unnecessary. Removed.

https://codereview.chromium.org/1278543002/diff/180001/Source/core/layout/Lay...
File Source/core/layout/LayoutInline.cpp (right):

https://codereview.chromium.org/1278543002/diff/180001/Source/core/layout/Lay...
Source/core/layout/LayoutInline.cpp:1375: 
On 2015/08/27 18:20:59, chrishtr wrote:
> spurious

Done.

[chrishtr, 2015-08-27 23:14:52]

https://codereview.chromium.org/1278543002/diff/200001/Source/core/layout/Lay...
File Source/core/layout/LayoutBlockFlowLine.cpp (right):

https://codereview.chromium.org/1278543002/diff/200001/Source/core/layout/Lay...
Source/core/layout/LayoutBlockFlowLine.cpp:1879:
outlineBounds.inflate(o.styleRef().outlineOutsetExtent());
Why do you need to include the outset extent of the inline?

[Xianzhu, 2015-08-27 23:40:15]

https://codereview.chromium.org/1278543002/diff/200001/Source/core/layout/Lay...
File Source/core/layout/LayoutBlockFlowLine.cpp (right):

https://codereview.chromium.org/1278543002/diff/200001/Source/core/layout/Lay...
Source/core/layout/LayoutBlockFlowLine.cpp:1879:
outlineBounds.inflate(o.styleRef().outlineOutsetExtent());
On 2015/08/27 23:14:52, chrishtr wrote:
> Why do you need to include the outset extent of the inline?

The contents visual overflow of a block should cover all visual overflows of all
descendants, so should also cover outlines of descendant inlines.

Line 1859-1864 accumulates visual overflows of line boxes. The visual overflow
of a line boxe includes outline outsets as if they have the outline of the
intersecting LayoutInlines, but doesn't include outlines of LayoutInline
continuations, so line 1865-1882 accumulates visual overflow of continuations of
LayoutInlines.

Previously we propagated outline style to LayoutInline continuations and let the
continuation paint their own outlines. This didn't require the visual overflow
to include outline of continuations, but caused complex logic of continuation
outline painting. (You can see how https://codereview.chromium.org/1224933002/
simplifies continuation outline painting. The CL description also mentions
this.)

[chrishtr, 2015-08-28 00:10:05]

https://codereview.chromium.org/1278543002/diff/200001/Source/core/layout/Lay...
File Source/core/layout/LayoutBlockFlowLine.cpp (right):

https://codereview.chromium.org/1278543002/diff/200001/Source/core/layout/Lay...
Source/core/layout/LayoutBlockFlowLine.cpp:1879:
outlineBounds.inflate(o.styleRef().outlineOutsetExtent());
On 2015/08/27 at 23:40:15, Xianzhu wrote:
> On 2015/08/27 23:14:52, chrishtr wrote:
> > Why do you need to include the outset extent of the inline?
> 
> The contents visual overflow of a block should cover all visual overflows of
all descendants, so should also cover outlines of descendant inlines.
> 
> Line 1859-1864 accumulates visual overflows of line boxes. The visual overflow
of a line boxe includes outline outsets as if they have the outline of the
intersecting LayoutInlines, but doesn't include outlines of LayoutInline
continuations, so line 1865-1882 accumulates visual overflow of continuations of
LayoutInlines.

Sure, but why is o.styleRef().outlineOutsetExtent() part of the overflow of a
continuation?

> 
> Previously we propagated outline style to LayoutInline continuations and let
the continuation paint their own outlines. This didn't require the visual
overflow to include outline of continuations, but caused complex logic of
continuation outline painting. (You can see how
https://codereview.chromium.org/1224933002/ simplifies continuation outline
painting. The CL description also mentions this.)

[Xianzhu, 2015-08-28 00:24:10]

https://codereview.chromium.org/1278543002/diff/200001/Source/core/layout/Lay...
File Source/core/layout/LayoutBlockFlowLine.cpp (right):

https://codereview.chromium.org/1278543002/diff/200001/Source/core/layout/Lay...
Source/core/layout/LayoutBlockFlowLine.cpp:1879:
outlineBounds.inflate(o.styleRef().outlineOutsetExtent());
On 2015/08/28 00:10:05, chrishtr wrote:
> On 2015/08/27 at 23:40:15, Xianzhu wrote:
> > On 2015/08/27 23:14:52, chrishtr wrote:
> > > Why do you need to include the outset extent of the inline?
> > 
> > The contents visual overflow of a block should cover all visual overflows of
> all descendants, so should also cover outlines of descendant inlines.
> > 
> > Line 1859-1864 accumulates visual overflows of line boxes. The visual
overflow
> of a line boxe includes outline outsets as if they have the outline of the
> intersecting LayoutInlines, but doesn't include outlines of LayoutInline
> continuations, so line 1865-1882 accumulates visual overflow of continuations
of
> LayoutInlines.
> 
> Sure, but why is o.styleRef().outlineOutsetExtent() part of the overflow of a
> continuation?

It's the visual outset of the outline outside of the outline rects. Outline
rects are just the rects that the outline will be drawn around of, doesn't
include the outline outset.

Added part of above as comment of LayoutObject::addOutlineRects().

[chrishtr, 2015-08-28 00:37:27]

lgtm

https://codereview.chromium.org/1278543002/diff/220001/Source/core/layout/Lay...
File Source/core/layout/LayoutObject.h (right):

https://codereview.chromium.org/1278543002/diff/220001/Source/core/layout/Lay...
Source/core/layout/LayoutObject.h:991: // Collects rectangles that the outline
of this object would be drawing around of,
s/around of/along the outside of/

[Xianzhu, 2015-08-28 03:48:05]

https://codereview.chromium.org/1278543002/diff/220001/Source/core/layout/Lay...
File Source/core/layout/LayoutObject.h (right):

https://codereview.chromium.org/1278543002/diff/220001/Source/core/layout/Lay...
Source/core/layout/LayoutObject.h:991: // Collects rectangles that the outline
of this object would be drawing around of,
On 2015/08/28 00:37:27, chrishtr wrote:
> s/around of/along the outside of/

Done.

[Xianzhu, 2015-08-28 03:48:09]

The CQ bit was checked by wangxianzhu@chromium.org

[commit-bot: I haz the power, 2015-08-28 03:48:17]

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

[Xianzhu, 2015-08-28 03:51:44]

The CQ bit was checked by wangxianzhu@chromium.org

[Xianzhu, 2015-08-28 03:51:44]

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/1278543002/#ps240001
(title: " ")

[commit-bot: I haz the power, 2015-08-28 03:51:51]

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

[commit-bot: I haz the power, 2015-08-28 04:59:31]

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

[commit-bot: I haz the power, 2015-08-28 04:59:32]

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_...)

[Xianzhu, 2015-08-28 16:19:16]

The CQ bit was checked by wangxianzhu@chromium.org

[Xianzhu, 2015-08-28 16:19:16]

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/1278543002/#ps260001
(title: " ")

[commit-bot: I haz the power, 2015-08-28 16:19:25]

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

[commit-bot: I haz the power, 2015-08-28 17:38:26]

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

[commit-bot: I haz the power, 2015-08-28 17:38:27]

Try jobs failed on following builders:
  linux_chromium_chromeos_rel_ng on tryserver.chromium.linux (JOB_FAILED,
http://build.chromium.org/p/tryserver.chromium.linux/builders/linux_chromium_...)

[Xianzhu, 2015-08-28 17:39:03]

The CQ bit was checked by wangxianzhu@chromium.org

[commit-bot: I haz the power, 2015-08-28 17:39:34]

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

[commit-bot: I haz the power, 2015-08-28 18:25:48]

Committed patchset #14 (id:260001) as
https://src.chromium.org/viewvc/blink?view=rev&revision=201418