[LayoutNG] Fix ShapingLineBreaker when the end of range is needed

[LayoutNG] Fix ShapingLineBreaker when the end of range is needed

This patch changes ShapingLineBreaker behavior when there is no break
opportunity within the range, and all glyphs can fit in the available
space.

NGLineBreaker expects the ShapeResult to the end of the range, and
handles breakability between the next item by itself in such case.

It used to expect whether there's a break opportunity at the end or not,
and the mock computed it anyway. The semantics was changed since
ShapingLineBreaker does not produce as part of other computation.

This patch enables ShapingLineBreaker by default, while keeping the mock
under #ifdef to ease the isolation of problems.

Most of test failures are ignorable, crashes turn to failures, minor
differences in measuring widths, or caused by other problems (e.g.,
innerText.)

spelling-huge-text.html looks problematic. ShapingLineBreaker is more
than 10 times slower for long lines (30k characters in single text node
in this case.) I have some hypothesis, but I'd like to defer the perf
until we get more real safe-to-break. Current mock safe-to-break
requires to reshape a lot, which is good to test reshape code, but is
not appropriate to look at the perf problems.

BUG=636993
Review-Url: https://codereview.chromium.org/2879093002
Cr-Commit-Position: refs/heads/master@{#478727}
Committed: https://chromium.googlesource.com/chromium/src/+/2476bc2b498e006eca452652f9436cf4cb7d12c5

[kojii, 2017-05-15 06:00:27]

Description was changed from

==========
ngslb

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

to

==========
ngslb

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

[kojii, 2017-06-01 05:45:32]

Patchset #6 (id:100001) has been deleted

[kojii, 2017-06-07 18:14:51]

Patchset #18 (id:360001) has been deleted

[kojii, 2017-06-08 04:42:58]

Description was changed from

==========
ngslb

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

to

==========
[LayoutNG] Fix ShapingLineBreaker when no break opportunity

This patch changes ShapingLineBreaker behavior when there is no break
opportunity within the range, and all glyphs can fit in the available
space.

NGLineBreaker expects the ShapeResult to the end of the range, and
handles breakability between the next item by itself in such case.

It used to expect whether there's a break opportunity at the end or not,
and the mock computed it anyway. The semantics was changed since
ShapingLineBreaker does not produce as part of other computation.

This patch enables ShapingLineBreaker by default, while keeping the mock
under #ifdef to ease the isolation of problems.

Most of test failures are ignorable, crashes turn to failures, or look
unrelated.

spelling-huge-text.html looks problematic. ShapingLineBreaker is more
than 10 times slower for long lines (30k characters in single text node
in this case.) I have some hypothesis, but I'd like to defer the perf
until we get more real safe-to-break. Current mock safe-to-break
requires to reshape a lot, which is good to test reshape code, but is
not appropriate to look at the perf problems.

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

[kojii, 2017-06-08 04:43:57]

Description was changed from

==========
[LayoutNG] Fix ShapingLineBreaker when no break opportunity

This patch changes ShapingLineBreaker behavior when there is no break
opportunity within the range, and all glyphs can fit in the available
space.

NGLineBreaker expects the ShapeResult to the end of the range, and
handles breakability between the next item by itself in such case.

It used to expect whether there's a break opportunity at the end or not,
and the mock computed it anyway. The semantics was changed since
ShapingLineBreaker does not produce as part of other computation.

This patch enables ShapingLineBreaker by default, while keeping the mock
under #ifdef to ease the isolation of problems.

Most of test failures are ignorable, crashes turn to failures, or look
unrelated.

spelling-huge-text.html looks problematic. ShapingLineBreaker is more
than 10 times slower for long lines (30k characters in single text node
in this case.) I have some hypothesis, but I'd like to defer the perf
until we get more real safe-to-break. Current mock safe-to-break
requires to reshape a lot, which is good to test reshape code, but is
not appropriate to look at the perf problems.

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

to

==========
[LayoutNG] Fix ShapingLineBreaker when no break opportunity

This patch changes ShapingLineBreaker behavior when there is no break
opportunity within the range, and all glyphs can fit in the available
space.

NGLineBreaker expects the ShapeResult to the end of the range, and
handles breakability between the next item by itself in such case.

It used to expect whether there's a break opportunity at the end or not,
and the mock computed it anyway. The semantics was changed since
ShapingLineBreaker does not produce as part of other computation.

This patch enables ShapingLineBreaker by default, while keeping the mock
under #ifdef to ease the isolation of problems.

Most of test failures are ignorable, crashes turn to failures, or minor
differences in measuring widths.

spelling-huge-text.html looks problematic. ShapingLineBreaker is more
than 10 times slower for long lines (30k characters in single text node
in this case.) I have some hypothesis, but I'd like to defer the perf
until we get more real safe-to-break. Current mock safe-to-break
requires to reshape a lot, which is good to test reshape code, but is
not appropriate to look at the perf problems.

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

[kojii, 2017-06-08 04:44:30]

Description was changed from

==========
[LayoutNG] Fix ShapingLineBreaker when no break opportunity

This patch changes ShapingLineBreaker behavior when there is no break
opportunity within the range, and all glyphs can fit in the available
space.

NGLineBreaker expects the ShapeResult to the end of the range, and
handles breakability between the next item by itself in such case.

It used to expect whether there's a break opportunity at the end or not,
and the mock computed it anyway. The semantics was changed since
ShapingLineBreaker does not produce as part of other computation.

This patch enables ShapingLineBreaker by default, while keeping the mock
under #ifdef to ease the isolation of problems.

Most of test failures are ignorable, crashes turn to failures, or minor
differences in measuring widths.

spelling-huge-text.html looks problematic. ShapingLineBreaker is more
than 10 times slower for long lines (30k characters in single text node
in this case.) I have some hypothesis, but I'd like to defer the perf
until we get more real safe-to-break. Current mock safe-to-break
requires to reshape a lot, which is good to test reshape code, but is
not appropriate to look at the perf problems.

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

to

==========
[LayoutNG] Fix ShapingLineBreaker when no break opportunity

This patch changes ShapingLineBreaker behavior when there is no break
opportunity within the range, and all glyphs can fit in the available
space.

NGLineBreaker expects the ShapeResult to the end of the range, and
handles breakability between the next item by itself in such case.

It used to expect whether there's a break opportunity at the end or not,
and the mock computed it anyway. The semantics was changed since
ShapingLineBreaker does not produce as part of other computation.

This patch enables ShapingLineBreaker by default, while keeping the mock
under #ifdef to ease the isolation of problems.

Most of test failures are ignorable, crashes turn to failures, minor
differences in measuring widths, or caused by other problems (e.g.,
innerText.)

spelling-huge-text.html looks problematic. ShapingLineBreaker is more
than 10 times slower for long lines (30k characters in single text node
in this case.) I have some hypothesis, but I'd like to defer the perf
until we get more real safe-to-break. Current mock safe-to-break
requires to reshape a lot, which is good to test reshape code, but is
not appropriate to look at the perf problems.

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

[kojii, 2017-06-08 04:44:42]

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

[kojii, 2017-06-08 04:44:44]

PTAL.

[kojii, 2017-06-08 05:23:30]

Description was changed from

==========
[LayoutNG] Fix ShapingLineBreaker when no break opportunity

This patch changes ShapingLineBreaker behavior when there is no break
opportunity within the range, and all glyphs can fit in the available
space.

NGLineBreaker expects the ShapeResult to the end of the range, and
handles breakability between the next item by itself in such case.

It used to expect whether there's a break opportunity at the end or not,
and the mock computed it anyway. The semantics was changed since
ShapingLineBreaker does not produce as part of other computation.

This patch enables ShapingLineBreaker by default, while keeping the mock
under #ifdef to ease the isolation of problems.

Most of test failures are ignorable, crashes turn to failures, minor
differences in measuring widths, or caused by other problems (e.g.,
innerText.)

spelling-huge-text.html looks problematic. ShapingLineBreaker is more
than 10 times slower for long lines (30k characters in single text node
in this case.) I have some hypothesis, but I'd like to defer the perf
until we get more real safe-to-break. Current mock safe-to-break
requires to reshape a lot, which is good to test reshape code, but is
not appropriate to look at the perf problems.

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

to

==========
[LayoutNG] Fix ShapingLineBreaker when the end of range is needed

This patch changes ShapingLineBreaker behavior when there is no break
opportunity within the range, and all glyphs can fit in the available
space.

NGLineBreaker expects the ShapeResult to the end of the range, and
handles breakability between the next item by itself in such case.

It used to expect whether there's a break opportunity at the end or not,
and the mock computed it anyway. The semantics was changed since
ShapingLineBreaker does not produce as part of other computation.

This patch enables ShapingLineBreaker by default, while keeping the mock
under #ifdef to ease the isolation of problems.

Most of test failures are ignorable, crashes turn to failures, minor
differences in measuring widths, or caused by other problems (e.g.,
innerText.)

spelling-huge-text.html looks problematic. ShapingLineBreaker is more
than 10 times slower for long lines (30k characters in single text node
in this case.) I have some hypothesis, but I'd like to defer the perf
until we get more real safe-to-break. Current mock safe-to-break
requires to reshape a lot, which is good to test reshape code, but is
not appropriate to look at the perf problems.

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

[kojii, 2017-06-08 05:23:58]

Description was changed from

==========
[LayoutNG] Fix ShapingLineBreaker when the end of range is needed

This patch changes ShapingLineBreaker behavior when there is no break
opportunity within the range, and all glyphs can fit in the available
space.

NGLineBreaker expects the ShapeResult to the end of the range, and
handles breakability between the next item by itself in such case.

It used to expect whether there's a break opportunity at the end or not,
and the mock computed it anyway. The semantics was changed since
ShapingLineBreaker does not produce as part of other computation.

This patch enables ShapingLineBreaker by default, while keeping the mock
under #ifdef to ease the isolation of problems.

Most of test failures are ignorable, crashes turn to failures, minor
differences in measuring widths, or caused by other problems (e.g.,
innerText.)

spelling-huge-text.html looks problematic. ShapingLineBreaker is more
than 10 times slower for long lines (30k characters in single text node
in this case.) I have some hypothesis, but I'd like to defer the perf
until we get more real safe-to-break. Current mock safe-to-break
requires to reshape a lot, which is good to test reshape code, but is
not appropriate to look at the perf problems.

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

to

==========
[LayoutNG] Fix ShapingLineBreaker when the end of range is needed

This patch changes ShapingLineBreaker behavior when there is no break
opportunity within the range, and all glyphs can fit in the available
space.

NGLineBreaker expects the ShapeResult to the end of the range, and
handles breakability between the next item by itself in such case.

It used to expect whether there's a break opportunity at the end or not,
and the mock computed it anyway. The semantics was changed since
ShapingLineBreaker does not produce as part of other computation.

This patch enables ShapingLineBreaker by default, while keeping the mock
under #ifdef to ease the isolation of problems.

Most of test failures are ignorable, crashes turn to failures, minor
differences in measuring widths, or caused by other problems (e.g.,
innerText.)

spelling-huge-text.html looks problematic. ShapingLineBreaker is more
than 10 times slower for long lines (30k characters in single text node
in this case.) I have some hypothesis, but I'd like to defer the perf
until we get more real safe-to-break. Current mock safe-to-break
requires to reshape a lot, which is good to test reshape code, but is
not appropriate to look at the perf problems.

BUG=636993
==========

[kojii, 2017-06-08 05:24:04]

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

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

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-06-08 07:14:03]

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

[commit-bot: I haz the power, 2017-06-08 07:14:04]

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-06-08 11:21:25]

Description was changed from

==========
[LayoutNG] Fix ShapingLineBreaker when the end of range is needed

This patch changes ShapingLineBreaker behavior when there is no break
opportunity within the range, and all glyphs can fit in the available
space.

NGLineBreaker expects the ShapeResult to the end of the range, and
handles breakability between the next item by itself in such case.

It used to expect whether there's a break opportunity at the end or not,
and the mock computed it anyway. The semantics was changed since
ShapingLineBreaker does not produce as part of other computation.

This patch enables ShapingLineBreaker by default, while keeping the mock
under #ifdef to ease the isolation of problems.

Most of test failures are ignorable, crashes turn to failures, minor
differences in measuring widths, or caused by other problems (e.g.,
innerText.)

spelling-huge-text.html looks problematic. ShapingLineBreaker is more
than 10 times slower for long lines (30k characters in single text node
in this case.) I have some hypothesis, but I'd like to defer the perf
until we get more real safe-to-break. Current mock safe-to-break
requires to reshape a lot, which is good to test reshape code, but is
not appropriate to look at the perf problems.

BUG=636993
==========

to

==========
[LayoutNG] Fix ShapingLineBreaker when the end of range is needed

This patch changes ShapingLineBreaker behavior when there is no break
opportunity within the range, and all glyphs can fit in the available
space.

NGLineBreaker expects the ShapeResult to the end of the range, and
handles breakability between the next item by itself in such case.

It used to expect whether there's a break opportunity at the end or not,
and the mock computed it anyway. The semantics was changed since
ShapingLineBreaker does not produce as part of other computation.

This patch enables ShapingLineBreaker by default, while keeping the mock
under #ifdef to ease the isolation of problems.

Most of test failures are ignorable, crashes turn to failures, minor
differences in measuring widths, or caused by other problems (e.g.,
innerText.)

spelling-huge-text.html looks problematic. ShapingLineBreaker is more
than 10 times slower for long lines (30k characters in single text node
in this case.) I have some hypothesis, but I'd like to defer the perf
until we get more real safe-to-break. Current mock safe-to-break
requires to reshape a lot, which is good to test reshape code, but is
not appropriate to look at the perf problems.

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

[kojii, 2017-06-08 11:21:29]

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

[commit-bot: I haz the power, 2017-06-08 11:21:39]

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-06-08 16:05:40]

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

[commit-bot: I haz the power, 2017-06-08 16:05:41]

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

[kojii, 2017-06-10 17:55:41]

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

[commit-bot: I haz the power, 2017-06-10 17:55:47]

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-06-10 21:34:11]

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

[commit-bot: I haz the power, 2017-06-10 21:34:12]

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

[eae, 2017-06-12 16:51:37]

https://codereview.chromium.org/2879093002/diff/420001/third_party/WebKit/Sou...
File third_party/WebKit/Source/platform/fonts/shaping/ShapingLineBreaker.cpp
(right):

https://codereview.chromium.org/2879093002/diff/420001/third_party/WebKit/Sou...
third_party/WebKit/Source/platform/fonts/shaping/ShapingLineBreaker.cpp:126: if
(candidate_break >= range_end) {
When would this happen?

[kojii, 2017-06-12 16:54:34]

https://codereview.chromium.org/2879093002/diff/420001/third_party/WebKit/Sou...
File third_party/WebKit/Source/platform/fonts/shaping/ShapingLineBreaker.cpp
(right):

https://codereview.chromium.org/2879093002/diff/420001/third_party/WebKit/Sou...
third_party/WebKit/Source/platform/fonts/shaping/ShapingLineBreaker.cpp:126: if
(candidate_break >= range_end) {
On 2017/06/12 at 16:51:37, eae wrote:
> When would this happen?

"==" happens when end_position >= result->Width(). ">" should never happen, so I
have DCHECK below.

[eae, 2017-06-12 17:11:03]

On 2017/06/12 16:54:34, kojii wrote:
>
https://codereview.chromium.org/2879093002/diff/420001/third_party/WebKit/Sou...
> File third_party/WebKit/Source/platform/fonts/shaping/ShapingLineBreaker.cpp
> (right):
> 
>
https://codereview.chromium.org/2879093002/diff/420001/third_party/WebKit/Sou...
> third_party/WebKit/Source/platform/fonts/shaping/ShapingLineBreaker.cpp:126:
if
> (candidate_break >= range_end) {
> On 2017/06/12 at 16:51:37, eae wrote:
> > When would this happen?
> 
> "==" happens when end_position >= result->Width(). ">" should never happen, so
I
> have DCHECK below.

Ah, makes sense. Didn't think about the == case.
Thanks for the clarification!

LGTM

[eae, 2017-06-12 17:11:18]

The CQ bit was checked by eae@chromium.org

[commit-bot: I haz the power, 2017-06-12 17:11:55]

CQ is trying da patch.

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

[kojii, 2017-06-12 19:37:15]

Description was changed from

==========
[LayoutNG] Fix ShapingLineBreaker when the end of range is needed

This patch changes ShapingLineBreaker behavior when there is no break
opportunity within the range, and all glyphs can fit in the available
space.

NGLineBreaker expects the ShapeResult to the end of the range, and
handles breakability between the next item by itself in such case.

It used to expect whether there's a break opportunity at the end or not,
and the mock computed it anyway. The semantics was changed since
ShapingLineBreaker does not produce as part of other computation.

This patch enables ShapingLineBreaker by default, while keeping the mock
under #ifdef to ease the isolation of problems.

Most of test failures are ignorable, crashes turn to failures, minor
differences in measuring widths, or caused by other problems (e.g.,
innerText.)

spelling-huge-text.html looks problematic. ShapingLineBreaker is more
than 10 times slower for long lines (30k characters in single text node
in this case.) I have some hypothesis, but I'd like to defer the perf
until we get more real safe-to-break. Current mock safe-to-break
requires to reshape a lot, which is good to test reshape code, but is
not appropriate to look at the perf problems.

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

to

==========
[LayoutNG] Fix ShapingLineBreaker when the end of range is needed

This patch changes ShapingLineBreaker behavior when there is no break
opportunity within the range, and all glyphs can fit in the available
space.

NGLineBreaker expects the ShapeResult to the end of the range, and
handles breakability between the next item by itself in such case.

It used to expect whether there's a break opportunity at the end or not,
and the mock computed it anyway. The semantics was changed since
ShapingLineBreaker does not produce as part of other computation.

This patch enables ShapingLineBreaker by default, while keeping the mock
under #ifdef to ease the isolation of problems.

Most of test failures are ignorable, crashes turn to failures, minor
differences in measuring widths, or caused by other problems (e.g.,
innerText.)

spelling-huge-text.html looks problematic. ShapingLineBreaker is more
than 10 times slower for long lines (30k characters in single text node
in this case.) I have some hypothesis, but I'd like to defer the perf
until we get more real safe-to-break. Current mock safe-to-break
requires to reshape a lot, which is good to test reshape code, but is
not appropriate to look at the perf problems.

BUG=636993
==========

[kojii, 2017-06-12 19:40:59]

The CQ bit was unchecked by kojii@chromium.org

[kojii, 2017-06-12 19:47:20]

The CQ bit was checked by kojii@chromium.org

[commit-bot: I haz the power, 2017-06-12 19:47:52]

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-06-12 19:54:14]

CQ is committing da patch.

Bot data: {"patchset_id": 420001, "attempt_start_ts": 1497296840546210,
"parent_rev": "db76a97fd74c4ee0e5f4c379a1289ee0f44ed7ea", "commit_rev":
"2476bc2b498e006eca452652f9436cf4cb7d12c5"}

[commit-bot: I haz the power, 2017-06-12 19:54:25]

Description was changed from

==========
[LayoutNG] Fix ShapingLineBreaker when the end of range is needed

This patch changes ShapingLineBreaker behavior when there is no break
opportunity within the range, and all glyphs can fit in the available
space.

NGLineBreaker expects the ShapeResult to the end of the range, and
handles breakability between the next item by itself in such case.

It used to expect whether there's a break opportunity at the end or not,
and the mock computed it anyway. The semantics was changed since
ShapingLineBreaker does not produce as part of other computation.

This patch enables ShapingLineBreaker by default, while keeping the mock
under #ifdef to ease the isolation of problems.

Most of test failures are ignorable, crashes turn to failures, minor
differences in measuring widths, or caused by other problems (e.g.,
innerText.)

spelling-huge-text.html looks problematic. ShapingLineBreaker is more
than 10 times slower for long lines (30k characters in single text node
in this case.) I have some hypothesis, but I'd like to defer the perf
until we get more real safe-to-break. Current mock safe-to-break
requires to reshape a lot, which is good to test reshape code, but is
not appropriate to look at the perf problems.

BUG=636993
==========

to

==========
[LayoutNG] Fix ShapingLineBreaker when the end of range is needed

This patch changes ShapingLineBreaker behavior when there is no break
opportunity within the range, and all glyphs can fit in the available
space.

NGLineBreaker expects the ShapeResult to the end of the range, and
handles breakability between the next item by itself in such case.

It used to expect whether there's a break opportunity at the end or not,
and the mock computed it anyway. The semantics was changed since
ShapingLineBreaker does not produce as part of other computation.

This patch enables ShapingLineBreaker by default, while keeping the mock
under #ifdef to ease the isolation of problems.

Most of test failures are ignorable, crashes turn to failures, minor
differences in measuring widths, or caused by other problems (e.g.,
innerText.)

spelling-huge-text.html looks problematic. ShapingLineBreaker is more
than 10 times slower for long lines (30k characters in single text node
in this case.) I have some hypothesis, but I'd like to defer the perf
until we get more real safe-to-break. Current mock safe-to-break
requires to reshape a lot, which is good to test reshape code, but is
not appropriate to look at the perf problems.

BUG=636993

Review-Url: https://codereview.chromium.org/2879093002
Cr-Commit-Position: refs/heads/master@{#478727}
Committed:
https://chromium.googlesource.com/chromium/src/+/2476bc2b498e006eca452652f943...
==========

[commit-bot: I haz the power, 2017-06-12 19:54:26]

Committed patchset #20 (id:420001) as
https://chromium.googlesource.com/chromium/src/+/2476bc2b498e006eca452652f943...