[LayoutNG] Refactor NGLineBreaker for ShapingLineBreaker

[LayoutNG] Refactor NGLineBreaker for ShapingLineBreaker

This patch refactors NGLineBreaker to match to the interface
ShapingLineBreaker provides.

This patch uses a mock of ShapingLineBreaker so that we can test
NGLineBreaker and ShapingLineBreaker independently. Integrating
ShapingLineBreaker will be after NGLineBreaker was stabilized.

This patch also changes the relationship of NGLineBreaker and
NGInlineLayoutAlgorithm. Measuring logic is moved to NGLineBreaker,
while NGInlineLayoutAlgorithm focuses on placing items and building line
boxes.

BUG=636993, 719615
CQ_INCLUDE_TRYBOTS=master.tryserver.chromium.linux:linux_layout_tests_layout_ng

Review-Url: https://codereview.chromium.org/2871733003
Cr-Commit-Position: refs/heads/master@{#471986}
Committed: https://chromium.googlesource.com/chromium/src/+/394d28a0fd538118bda1b530c1a37414ea28dbe0

[kojii, 2017-05-09 14:38:25]

Description was changed from

==========
nglb

BUG=
==========

to

==========
[LayoutNG] Refactor NGLineBreaker for ShapingLineBreaker


BUG=636993
CQ_INCLUDE_TRYBOTS=master.tryserver.chromium.linux:linux_layout_tests_layout_ng
==========

[kojii, 2017-05-10 14:11:04]

Patchset #6 (id:100001) has been deleted

[kojii, 2017-05-10 20:04:50]

Description was changed from

==========
[LayoutNG] Refactor NGLineBreaker for ShapingLineBreaker


BUG=636993
CQ_INCLUDE_TRYBOTS=master.tryserver.chromium.linux:linux_layout_tests_layout_ng
==========

to

==========
[LayoutNG] Refactor NGLineBreaker for ShapingLineBreaker

This patch refactors NGLineBreaker to match to the interface
ShapingLineBreaker provides.

This patch uses a mock of ShapingLineBreaker so that we can test
NGLineBreaker and ShapingLineBreaker independently. Integrating
ShapingLineBreaker will be after NGLineBreaker was stabilized.

This patch also changes the relationship of NGLineBreaker and
NGInlineLayoutAlgorithm. Measuring and line breaking are moved to
NGLineBreaker, while NGInlineLayoutAlgorithm focuses on placing items
and building line boxes.

BUG=636993, 719615
CQ_INCLUDE_TRYBOTS=master.tryserver.chromium.linux:linux_layout_tests_layout_ng
==========

[kojii, 2017-05-10 20:08:50]

kojii@chromium.org changed reviewers:
+ eae@chromium.org, ikilpatrick@chromium.org

[kojii, 2017-05-10 20:08:51]

Still WIP, some tests are failing, but the overall shapes and interfaces are
reviewable.

Great if there were any early feedback, or if you're too busy, reviewing after
all tests pass is fine.

[eae, 2017-05-10 21:31:38]

This is super exciting, thanks for taking this on!

https://codereview.chromium.org/2871733003/diff/140001/third_party/WebKit/Sou...
File third_party/WebKit/Source/core/layout/ng/inline/ng_inline_item.h (right):

https://codereview.chromium.org/2871733003/diff/140001/third_party/WebKit/Sou...
third_party/WebKit/Source/core/layout/ng/inline/ng_inline_item.h:69: const
ShapeResult* GetShapeResult() const { return shape_result_.Get(); }
I've been using the method name TextShapeResult() for this.

https://codereview.chromium.org/2871733003/diff/140001/third_party/WebKit/Sou...
File third_party/WebKit/Source/core/layout/ng/inline/ng_inline_item_result.h
(right):

https://codereview.chromium.org/2871733003/diff/140001/third_party/WebKit/Sou...
third_party/WebKit/Source/core/layout/ng/inline/ng_inline_item_result.h:16: //
line boxes are stored in NGInlineItemResults.
Add a comment explaining that this is a transient context object.

How about marking it as stack allocated?

https://codereview.chromium.org/2871733003/diff/140001/third_party/WebKit/Sou...
File
third_party/WebKit/Source/core/layout/ng/inline/ng_inline_layout_algorithm.cc
(right):

https://codereview.chromium.org/2871733003/diff/140001/third_party/WebKit/Sou...
third_party/WebKit/Source/core/layout/ng/inline/ng_inline_layout_algorithm.cc:82:
if (break_token && (break_token->TextOffset() || break_token->ItemIndex())) {
Why does this disable first line rules?

https://codereview.chromium.org/2871733003/diff/140001/third_party/WebKit/Sou...
third_party/WebKit/Source/core/layout/ng/inline/ng_inline_layout_algorithm.cc:346:
NGInlineItemResult* item_result,
Can we turn this const? If so a const reference would be ideal. If we can't make
it const then a pointer is the right call.

https://codereview.chromium.org/2871733003/diff/140001/third_party/WebKit/Sou...
File third_party/WebKit/Source/core/layout/ng/inline/ng_inline_node.cc (right):

https://codereview.chromium.org/2871733003/diff/140001/third_party/WebKit/Sou...
third_party/WebKit/Source/core/layout/ng/inline/ng_inline_node.cc:220: {
Could we break these blocks out into separate static functions or private
members? Or better yet, perhaps a single templetized one so we can share the
bulk of the logic?

https://codereview.chromium.org/2871733003/diff/140001/third_party/WebKit/Sou...
File third_party/WebKit/Source/core/layout/ng/inline/ng_line_breaker.cc (right):

https://codereview.chromium.org/2871733003/diff/140001/third_party/WebKit/Sou...
third_party/WebKit/Source/core/layout/ng/inline/ng_line_breaker.cc:140:
HarfBuzzShaper shaper(node_->Text().Characters16(), node_->Text().length());
The shaper and ShapingLineBreaker instances should probably be created outside
of the loop as they both operate on the entire content of the node.

[kojii, 2017-05-11 03:07:28]

Description was changed from

==========
[LayoutNG] Refactor NGLineBreaker for ShapingLineBreaker

This patch refactors NGLineBreaker to match to the interface
ShapingLineBreaker provides.

This patch uses a mock of ShapingLineBreaker so that we can test
NGLineBreaker and ShapingLineBreaker independently. Integrating
ShapingLineBreaker will be after NGLineBreaker was stabilized.

This patch also changes the relationship of NGLineBreaker and
NGInlineLayoutAlgorithm. Measuring and line breaking are moved to
NGLineBreaker, while NGInlineLayoutAlgorithm focuses on placing items
and building line boxes.

BUG=636993, 719615
CQ_INCLUDE_TRYBOTS=master.tryserver.chromium.linux:linux_layout_tests_layout_ng
==========

to

==========
[LayoutNG] Refactor NGLineBreaker for ShapingLineBreaker

This patch refactors NGLineBreaker to match to the interface
ShapingLineBreaker provides.

This patch uses a mock of ShapingLineBreaker so that we can test
NGLineBreaker and ShapingLineBreaker independently. Integrating
ShapingLineBreaker will be after NGLineBreaker was stabilized.

This patch also changes the relationship of NGLineBreaker and
NGInlineLayoutAlgorithm. Measuring logic is moved to NGLineBreaker,
while NGInlineLayoutAlgorithm focuses on placing items and building line
boxes.

BUG=636993, 719615
CQ_INCLUDE_TRYBOTS=master.tryserver.chromium.linux:linux_layout_tests_layout_ng
==========

[ikilpatrick, 2017-05-11 15:55:56]

https://codereview.chromium.org/2871733003/diff/160001/third_party/WebKit/Sou...
File
third_party/WebKit/Source/core/layout/ng/inline/ng_inline_layout_algorithm.cc
(right):

https://codereview.chromium.org/2871733003/diff/160001/third_party/WebKit/Sou...
third_party/WebKit/Source/core/layout/ng/inline/ng_inline_layout_algorithm.cc:402:
line_breaker.NextLine(&item_results, this);
So it'd be nice if we didn't have the shaper calling the algorithm, is it
possible to.... (see other file).

https://codereview.chromium.org/2871733003/diff/160001/third_party/WebKit/Sou...
File third_party/WebKit/Source/core/layout/ng/inline/ng_line_breaker.cc (right):

https://codereview.chromium.org/2871733003/diff/160001/third_party/WebKit/Sou...
third_party/WebKit/Source/core/layout/ng/inline/ng_line_breaker.cc:105: while
(item_index < items.size()) {
... move this for loop into NGInlineLayoutAlgorithm::Layout...

this function would just take:

NGLineBreaker::NextLine(const NGLayoutOpportunity&, NGInlineItemResults*
item_results)

the code which does the kAtomicInline, kFloating etc, would move out... and this
would soley just deal with text if that makes sense.

I can also have a shot at doing this next week if this doesn't make sense :)

[kojii, 2017-05-11 16:16:56]

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

[kojii, 2017-05-11 16:17:36]

Thank you for the prompt review as always, all done and tests were fixed.
Replies inline:

https://codereview.chromium.org/2871733003/diff/140001/third_party/WebKit/Sou...
File third_party/WebKit/Source/core/layout/ng/inline/ng_inline_item.h (right):

https://codereview.chromium.org/2871733003/diff/140001/third_party/WebKit/Sou...
third_party/WebKit/Source/core/layout/ng/inline/ng_inline_item.h:69: const
ShapeResult* GetShapeResult() const { return shape_result_.Get(); }
On 2017/05/10 at 21:31:38, eae wrote:
> I've been using the method name TextShapeResult() for this.

I like that! ;)

https://codereview.chromium.org/2871733003/diff/140001/third_party/WebKit/Sou...
File third_party/WebKit/Source/core/layout/ng/inline/ng_inline_item_result.h
(right):

https://codereview.chromium.org/2871733003/diff/140001/third_party/WebKit/Sou...
third_party/WebKit/Source/core/layout/ng/inline/ng_inline_item_result.h:16: //
line boxes are stored in NGInlineItemResults.
On 2017/05/10 at 21:31:38, eae wrote:
> Add a comment explaining that this is a transient context object.
> 
> How about marking it as stack allocated?

Made DISALLOW_NEW_EXCEPT_PLACEMENT_NEW() to allow a vector of this. Thank you
for pointing out memory-related thing I often forget to take care of.

https://codereview.chromium.org/2871733003/diff/140001/third_party/WebKit/Sou...
File
third_party/WebKit/Source/core/layout/ng/inline/ng_inline_layout_algorithm.cc
(right):

https://codereview.chromium.org/2871733003/diff/140001/third_party/WebKit/Sou...
third_party/WebKit/Source/core/layout/ng/inline/ng_inline_layout_algorithm.cc:82:
if (break_token && (break_token->TextOffset() || break_token->ItemIndex())) {
On 2017/05/10 at 21:31:38, eae wrote:
> Why does this disable first line rules?

Comments added and code clarified better.

https://codereview.chromium.org/2871733003/diff/140001/third_party/WebKit/Sou...
third_party/WebKit/Source/core/layout/ng/inline/ng_inline_layout_algorithm.cc:346:
NGInlineItemResult* item_result,
On 2017/05/10 at 21:31:38, eae wrote:
> Can we turn this const? If so a const reference would be ideal. If we can't
make it const then a pointer is the right call.

Currently we can, but when we support painting, this function will std::move()
the fragment. Added comment.

https://codereview.chromium.org/2871733003/diff/140001/third_party/WebKit/Sou...
File third_party/WebKit/Source/core/layout/ng/inline/ng_inline_node.cc (right):

https://codereview.chromium.org/2871733003/diff/140001/third_party/WebKit/Sou...
third_party/WebKit/Source/core/layout/ng/inline/ng_inline_node.cc:220: {
On 2017/05/10 at 21:31:38, eae wrote:
> Could we break these blocks out into separate static functions or private
members? Or better yet, perhaps a single templetized one so we can share the
bulk of the logic?

Done. I'd like this to be more efficient than running two line breaking,
hopefully before we ship. Added comment.

https://codereview.chromium.org/2871733003/diff/140001/third_party/WebKit/Sou...
File third_party/WebKit/Source/core/layout/ng/inline/ng_line_breaker.cc (right):

https://codereview.chromium.org/2871733003/diff/140001/third_party/WebKit/Sou...
third_party/WebKit/Source/core/layout/ng/inline/ng_line_breaker.cc:140:
HarfBuzzShaper shaper(node_->Text().Characters16(), node_->Text().length());
On 2017/05/10 at 21:31:38, eae wrote:
> The shaper and ShapingLineBreaker instances should probably be created outside
of the loop as they both operate on the entire content of the node.

Done for HarfBuzzShaper, added comment for ShapingLineBreaker.

[commit-bot: I haz the power, 2017-05-11 16:17:48]

Dry run: CQ is trying da patch.

Follow status at:
https://chromium-cq-status.appspot.com/v2/patch-status/codereview.chromium.or...

[kojii, 2017-05-11 16:18:29]

Thank you for your prompt review too.

https://codereview.chromium.org/2871733003/diff/160001/third_party/WebKit/Sou...
File third_party/WebKit/Source/core/layout/ng/inline/ng_line_breaker.cc (right):

https://codereview.chromium.org/2871733003/diff/160001/third_party/WebKit/Sou...
third_party/WebKit/Source/core/layout/ng/inline/ng_line_breaker.cc:105: while
(item_index < items.size()) {
On 2017/05/11 at 15:55:55, ikilpatrick wrote:
> ... move this for loop into NGInlineLayoutAlgorithm::Layout...
> 
> this function would just take:
> 
> NGLineBreaker::NextLine(const NGLayoutOpportunity&, NGInlineItemResults*
item_results)
> 
> the code which does the kAtomicInline, kFloating etc, would move out... and
this would soley just deal with text if that makes sense.
> 
> I can also have a shot at doing this next week if this doesn't make sense :)

I don't like NGLineBreaker taking NGInlineLayoutAlgorithm as an argument either,
have a TODO comment in local to consider further refactoring.

If possible, I'd like classes for different pipeline stages than for different
target objects. Text and atomic inlines are really the same abstraction for the
line breaking purposes, and line breaker needs to traverse back and forth over a
mix of them in overflow and some other cases. Separating these two makes the
line breaker more complicated. Objects should be abstracted and handled in the
same way as much as possible.

Different pipeline stages I meant, this patch makes NGLineBreaker to own
measuring, so that we can make a single directional pipeline; measure, break,
and build a line. If NGInlineLayoutAlgorithm owns measuring, the flow goes
NGInlineLayoutAlgorithm -> NGLineBreaker -> NGInlineLayoutAlgorithm. This makes
the two classes more tightly coupled.

I'm fine to make yet another class to measure all kind of objects if desired,
but I'm not positive for NGInlineLayoutAlgorithm to own all measuring except for
text.

Currently, floats is preventing the single directional pipeline, because it
requires container builder (build) but affects available width (measure). I need
to study a bit more on floats how to cut this bi-directional dependency.

[eae, 2017-05-11 16:25:18]

LGTM

https://codereview.chromium.org/2871733003/diff/140001/third_party/WebKit/Sou...
File third_party/WebKit/Source/core/layout/ng/inline/ng_line_breaker.cc (right):

https://codereview.chromium.org/2871733003/diff/140001/third_party/WebKit/Sou...
third_party/WebKit/Source/core/layout/ng/inline/ng_line_breaker.cc:140:
HarfBuzzShaper shaper(node_->Text().Characters16(), node_->Text().length());
On 2017/05/11 16:17:36, kojii wrote:
> On 2017/05/10 at 21:31:38, eae wrote:
> > The shaper and ShapingLineBreaker instances should probably be created
outside
> of the loop as they both operate on the entire content of the node.
> 
> Done for HarfBuzzShaper, added comment for ShapingLineBreaker.

Thanks!

[commit-bot: I haz the power, 2017-05-11 17:27:38]

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

[commit-bot: I haz the power, 2017-05-11 17:27:39]

Dry run: Try jobs failed on following builders:
  android_n5x_swarming_rel on master.tryserver.chromium.android (JOB_FAILED,
https://build.chromium.org/p/tryserver.chromium.android/builders/android_n5x_...)

[kojii, 2017-05-11 20:50:15]

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

[commit-bot: I haz the power, 2017-05-11 20:51:46]

Dry run: CQ is trying da patch.

Follow status at:
https://chromium-cq-status.appspot.com/v2/patch-status/codereview.chromium.or...

[commit-bot: I haz the power, 2017-05-11 23:29:29]

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

[commit-bot: I haz the power, 2017-05-11 23:29:31]

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

[kojii, 2017-05-13 15:20:57]

Ian, are you ok with this?

[kojii, 2017-05-14 08:08:24]

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

[commit-bot: I haz the power, 2017-05-14 08:08:36]

Dry run: CQ is trying da patch.

Follow status at:
https://chromium-cq-status.appspot.com/v2/patch-status/codereview.chromium.or...

[commit-bot: I haz the power, 2017-05-14 09:28:14]

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

[commit-bot: I haz the power, 2017-05-14 09:28:15]

Dry run: Try jobs failed on following builders:
  linux_layout_tests_layout_ng on master.tryserver.chromium.linux (JOB_FAILED,
http://build.chromium.org/p/tryserver.chromium.linux/builders/linux_layout_te...)

[kojii, 2017-05-14 13:00:31]

Patchset #11 (id:220001) has been deleted

[kojii, 2017-05-14 13:27:16]

Read some floats code and here's my thoughts atm.

With this CL, line breaking and line building are split and independent from
each other -- almost, except for floats. Given we need to put more algorithm
into each category, I think this split is good. It might also make us easier to
implement, say, multi-line line breaking.

Currently, floats is tightly coupled with NGConstraintSpace,
NGBoxFragmentBuilder, and NGBlockLayoutAlgorithm. NGLineBreaker should not know
about the latter two. I have some ideas to de-couple them more, but you might be
moving towards to different direction so I'd like the discussion separated from
this.

If we want floats to be tightly coupled with these classes, I think we're fine
not to support multi-line line breaking and other advanced line breakers when
floats exist. Handling floats in such complex algorithm is hard, I think we
might not do it anyway, and we have more time to think about this.

I agree with you that floats being the only exception isn't great. But I'd
rather prefer to keep loose coupling where possible, and consider de-coupling
floats in future, rather than making all objects tightly coupled because floats
is so.

[kojii, 2017-05-14 17:52:33]

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

[commit-bot: I haz the power, 2017-05-14 17:52:39]

Dry run: CQ is trying da patch.

Follow status at:
https://chromium-cq-status.appspot.com/v2/patch-status/codereview.chromium.or...

[kojii, 2017-05-14 18:10:26]

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

[commit-bot: I haz the power, 2017-05-14 18:10:31]

Dry run: CQ is trying da patch.

Follow status at:
https://chromium-cq-status.appspot.com/v2/patch-status/codereview.chromium.or...

[kojii, 2017-05-14 18:17:54]

Patchset #12 (id:260001) has been deleted

[commit-bot: I haz the power, 2017-05-14 21:36:06]

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

[commit-bot: I haz the power, 2017-05-14 21:36:07]

Dry run: This issue passed the CQ dry run.

[kojii, 2017-05-15 14:52:59]

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

[commit-bot: I haz the power, 2017-05-15 14:53:16]

Dry run: CQ is trying da patch.

Follow status at:
https://chromium-cq-status.appspot.com/v2/patch-status/codereview.chromium.or...

[commit-bot: I haz the power, 2017-05-15 15:47:55]

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

[commit-bot: I haz the power, 2017-05-15 15:47:56]

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

[ikilpatrick, 2017-05-16 00:04:18]

On 2017/05/14 13:27:16, kojii wrote:
> Read some floats code and here's my thoughts atm.
> 
> With this CL, line breaking and line building are split and independent from
> each other -- almost, except for floats. Given we need to put more algorithm
> into each category, I think this split is good. It might also make us easier
to
> implement, say, multi-line line breaking.
> 
> Currently, floats is tightly coupled with NGConstraintSpace,
> NGBoxFragmentBuilder, and NGBlockLayoutAlgorithm. NGLineBreaker should not
know
> about the latter two. I have some ideas to de-couple them more, but you might
be
> moving towards to different direction so I'd like the discussion separated
from
> this.
> 
> If we want floats to be tightly coupled with these classes, I think we're fine
> not to support multi-line line breaking and other advanced line breakers when
> floats exist. Handling floats in such complex algorithm is hard, I think we
> might not do it anyway, and we have more time to think about this.
> 
> I agree with you that floats being the only exception isn't great. But I'd
> rather prefer to keep loose coupling where possible, and consider de-coupling
> floats in future, rather than making all objects tightly coupled because
floats
> is so.

lgtm - Yeah I might have a go at cleaning it up some more later this week if
that's ok.

[kojii, 2017-05-16 01:23:57]

Thank you Ian. Yeah, this needs lots of cleanup, your help is great.

A bit later is better probably to avoid conflicts. This is still very initial
rough to debug ShapingLineBreaker, I'm expecting a few following CLs, in
addition to supporting inline margins, <br> tag, etc. so that -expected files
render correctly. I'm seeing many -expected files render incorrectly due to lack
of them and it's blocking gleb/alex.

By enabling the ShapingLineBreaker, I'm seeing only less than 100
failures/crashes, so I hope it's not too far to enable it.

[kojii, 2017-05-16 01:24:31]

The CQ bit was checked by kojii@chromium.org

[kojii, 2017-05-16 01:24:32]

The patchset sent to the CQ was uploaded after l-g-t-m from eae@chromium.org
Link to the patchset: https://codereview.chromium.org/2871733003/#ps300001
(title: "Cleanup")

[commit-bot: I haz the power, 2017-05-16 01:25:21]

CQ is trying da patch.

Follow status at:
https://chromium-cq-status.appspot.com/v2/patch-status/codereview.chromium.or...

[commit-bot: I haz the power, 2017-05-16 02:26:29]

CQ is committing da patch.

Bot data: {"patchset_id": 300001, "attempt_start_ts": 1494897871894740,
"parent_rev": "6a9e77ef378c0c835fc9d3265addb0c0d7bd911b", "commit_rev":
"394d28a0fd538118bda1b530c1a37414ea28dbe0"}

[commit-bot: I haz the power, 2017-05-16 02:26:45]

Description was changed from

==========
[LayoutNG] Refactor NGLineBreaker for ShapingLineBreaker

This patch refactors NGLineBreaker to match to the interface
ShapingLineBreaker provides.

This patch uses a mock of ShapingLineBreaker so that we can test
NGLineBreaker and ShapingLineBreaker independently. Integrating
ShapingLineBreaker will be after NGLineBreaker was stabilized.

This patch also changes the relationship of NGLineBreaker and
NGInlineLayoutAlgorithm. Measuring logic is moved to NGLineBreaker,
while NGInlineLayoutAlgorithm focuses on placing items and building line
boxes.

BUG=636993, 719615
CQ_INCLUDE_TRYBOTS=master.tryserver.chromium.linux:linux_layout_tests_layout_ng
==========

to

==========
[LayoutNG] Refactor NGLineBreaker for ShapingLineBreaker

This patch refactors NGLineBreaker to match to the interface
ShapingLineBreaker provides.

This patch uses a mock of ShapingLineBreaker so that we can test
NGLineBreaker and ShapingLineBreaker independently. Integrating
ShapingLineBreaker will be after NGLineBreaker was stabilized.

This patch also changes the relationship of NGLineBreaker and
NGInlineLayoutAlgorithm. Measuring logic is moved to NGLineBreaker,
while NGInlineLayoutAlgorithm focuses on placing items and building line
boxes.

BUG=636993, 719615
CQ_INCLUDE_TRYBOTS=master.tryserver.chromium.linux:linux_layout_tests_layout_ng

Review-Url: https://codereview.chromium.org/2871733003
Cr-Commit-Position: refs/heads/master@{#471986}
Committed:
https://chromium.googlesource.com/chromium/src/+/394d28a0fd538118bda1b530c1a3...
==========

[commit-bot: I haz the power, 2017-05-16 02:26:46]

Committed patchset #13 (id:300001) as
https://chromium.googlesource.com/chromium/src/+/394d28a0fd538118bda1b530c1a3...