Fix TextIterator's behavior with first-letter

Fix TextIterator's behavior with first-letter

TextIterator's behavior with first-letter is broken:
1. If its starts in a text node with first-letter and the starting
offset is non-zero, wrong text is passed to its text state.
2. When the text state is handling the remaining text of first-letter,
it doesn't consider the length of first-letter, and hence, reports
wrong offsets of the current text.

To fix 2, this patch makes the text state remember the length of
first-letter, and use it to adjust the output of
start/endOffsetInCurrentContainer.

To fix 1, given that the current behavior is correct when we start in
a text node at offset 0 (even with first-letter), this patch performs
a reduction that:
- start iterating with offset 0 instead of the given start offset
- have extra calls of |advance()| during initialization so that we have
moved to the given start position when initialization ends
- adjust text run start and end offsets when emitting text of the starting
text node

This patch partially corrects the behavior in two layout tests:
- editing/selection/extend-by-word-002.html
- editing/text-iterator/first-letter-word-boundary.html
The tests are still failing for other reasons, see crbug.com/671104

This patch is not an ultimate fix of TextIterator's behavior with
first-letter, but more like a first-aid hack built upon the current design.
In the long term, we should rewrite TextIterator.

BUG=647080
Committed: https://crrev.com/5185769b9ba7e9239d68c7dc672a27dd19b1685f
Cr-Commit-Position: refs/heads/master@{#436255}

[Xiaocheng, 2016-12-01 08:49:43]

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

[commit-bot: I haz the power, 2016-12-01 08:49:59]

Dry run: CQ is trying da patch. Follow status at
 
https://chromium-cq-status.appspot.com/v2/patch-status/codereview.chromium.or...

[Xiaocheng, 2016-12-01 09:07:07]

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

[commit-bot: I haz the power, 2016-12-01 09:07:31]

Dry run: CQ is trying da patch. Follow status at
 
https://chromium-cq-status.appspot.com/v2/patch-status/codereview.chromium.or...

[Xiaocheng, 2016-12-01 09:15:24]

Description was changed from

==========
Fix TextIterator's behavior with first-letter

BUG=647080
==========

to

==========
Fix TextIterator's behavior with first-letter

TextIterator's behavior with first-letter is broken:
1. If its starts in a text node with first-letter and the starting
offset is non-zero, wrong text is passed to its text state.
2. When the text state is handling the remaining text of first-letter,
it doesn't consider the length of first-letter, and hence, reports
wrong offsets of the current text.

To fix 2, this patch makes the text state remember the length of
first-letter, and use it to adjust the output of
start/endOffsetInCurrentContainer.

To fix 1, given that the current behavior is correct when we start in
a text node at offset 0 (even with first-letter), this patch performs
a reduction that:
- start iterating with offset 0 instead of the given start offset
- have extra calls of |advance()| during initialization so that we have
moved to the given start position when initialization ends
- adjust text run start and end offsets when emitting text of the starting
text node

BUG=647080
==========

[Xiaocheng, 2016-12-01 09:16:33]

Description was changed from

==========
Fix TextIterator's behavior with first-letter

TextIterator's behavior with first-letter is broken:
1. If its starts in a text node with first-letter and the starting
offset is non-zero, wrong text is passed to its text state.
2. When the text state is handling the remaining text of first-letter,
it doesn't consider the length of first-letter, and hence, reports
wrong offsets of the current text.

To fix 2, this patch makes the text state remember the length of
first-letter, and use it to adjust the output of
start/endOffsetInCurrentContainer.

To fix 1, given that the current behavior is correct when we start in
a text node at offset 0 (even with first-letter), this patch performs
a reduction that:
- start iterating with offset 0 instead of the given start offset
- have extra calls of |advance()| during initialization so that we have
moved to the given start position when initialization ends
- adjust text run start and end offsets when emitting text of the starting
text node

BUG=647080
==========

to

==========
Fix TextIterator's behavior with first-letter

TextIterator's behavior with first-letter is broken:
1. If its starts in a text node with first-letter and the starting
offset is non-zero, wrong text is passed to its text state.
2. When the text state is handling the remaining text of first-letter,
it doesn't consider the length of first-letter, and hence, reports
wrong offsets of the current text.

To fix 2, this patch makes the text state remember the length of
first-letter, and use it to adjust the output of
start/endOffsetInCurrentContainer.

To fix 1, given that the current behavior is correct when we start in
a text node at offset 0 (even with first-letter), this patch performs
a reduction that:
- start iterating with offset 0 instead of the given start offset
- have extra calls of |advance()| during initialization so that we have
moved to the given start position when initialization ends
- adjust text run start and end offsets when emitting text of the starting
text node

This patch also corrects the behavior in two layout tests:
- editing/selection/extend-by-word-002.html
- editing/text-iterator/first-letter-word-boundary.html

BUG=647080
==========

[Xiaocheng, 2016-12-01 09:17:47]

Description was changed from

==========
Fix TextIterator's behavior with first-letter

TextIterator's behavior with first-letter is broken:
1. If its starts in a text node with first-letter and the starting
offset is non-zero, wrong text is passed to its text state.
2. When the text state is handling the remaining text of first-letter,
it doesn't consider the length of first-letter, and hence, reports
wrong offsets of the current text.

To fix 2, this patch makes the text state remember the length of
first-letter, and use it to adjust the output of
start/endOffsetInCurrentContainer.

To fix 1, given that the current behavior is correct when we start in
a text node at offset 0 (even with first-letter), this patch performs
a reduction that:
- start iterating with offset 0 instead of the given start offset
- have extra calls of |advance()| during initialization so that we have
moved to the given start position when initialization ends
- adjust text run start and end offsets when emitting text of the starting
text node

This patch also corrects the behavior in two layout tests:
- editing/selection/extend-by-word-002.html
- editing/text-iterator/first-letter-word-boundary.html

BUG=647080
==========

to

==========
Fix TextIterator's behavior with first-letter

TextIterator's behavior with first-letter is broken:
1. If its starts in a text node with first-letter and the starting
offset is non-zero, wrong text is passed to its text state.
2. When the text state is handling the remaining text of first-letter,
it doesn't consider the length of first-letter, and hence, reports
wrong offsets of the current text.

To fix 2, this patch makes the text state remember the length of
first-letter, and use it to adjust the output of
start/endOffsetInCurrentContainer.

To fix 1, given that the current behavior is correct when we start in
a text node at offset 0 (even with first-letter), this patch performs
a reduction that:
- start iterating with offset 0 instead of the given start offset
- have extra calls of |advance()| during initialization so that we have
moved to the given start position when initialization ends
- adjust text run start and end offsets when emitting text of the starting
text node

This patch also corrects the behavior in two layout tests:
- editing/selection/extend-by-word-002.html
- editing/text-iterator/first-letter-word-boundary.html

This patch is not an ultimate fix of TextIterator's behavior with
first-letter, but more like a first-aid hack. In the long term, we should
rewrite TextIterator.

BUG=647080
==========

[Xiaocheng, 2016-12-01 09:18:13]

Description was changed from

==========
Fix TextIterator's behavior with first-letter

TextIterator's behavior with first-letter is broken:
1. If its starts in a text node with first-letter and the starting
offset is non-zero, wrong text is passed to its text state.
2. When the text state is handling the remaining text of first-letter,
it doesn't consider the length of first-letter, and hence, reports
wrong offsets of the current text.

To fix 2, this patch makes the text state remember the length of
first-letter, and use it to adjust the output of
start/endOffsetInCurrentContainer.

To fix 1, given that the current behavior is correct when we start in
a text node at offset 0 (even with first-letter), this patch performs
a reduction that:
- start iterating with offset 0 instead of the given start offset
- have extra calls of |advance()| during initialization so that we have
moved to the given start position when initialization ends
- adjust text run start and end offsets when emitting text of the starting
text node

This patch also corrects the behavior in two layout tests:
- editing/selection/extend-by-word-002.html
- editing/text-iterator/first-letter-word-boundary.html

This patch is not an ultimate fix of TextIterator's behavior with
first-letter, but more like a first-aid hack. In the long term, we should
rewrite TextIterator.

BUG=647080
==========

to

==========
Fix TextIterator's behavior with first-letter

TextIterator's behavior with first-letter is broken:
1. If its starts in a text node with first-letter and the starting
offset is non-zero, wrong text is passed to its text state.
2. When the text state is handling the remaining text of first-letter,
it doesn't consider the length of first-letter, and hence, reports
wrong offsets of the current text.

To fix 2, this patch makes the text state remember the length of
first-letter, and use it to adjust the output of
start/endOffsetInCurrentContainer.

To fix 1, given that the current behavior is correct when we start in
a text node at offset 0 (even with first-letter), this patch performs
a reduction that:
- start iterating with offset 0 instead of the given start offset
- have extra calls of |advance()| during initialization so that we have
moved to the given start position when initialization ends
- adjust text run start and end offsets when emitting text of the starting
text node

This patch also corrects the behavior in two layout tests:
- editing/selection/extend-by-word-002.html
- editing/text-iterator/first-letter-word-boundary.html

This patch is not an ultimate fix of TextIterator's behavior with
first-letter, but more like a first-aid hack built upon the current design.
In the long term, we should rewrite TextIterator.

BUG=647080
==========

[Xiaocheng, 2016-12-01 09:18:27]

xiaochengh@chromium.org changed reviewers:
+ yosin@chromium.org

[Xiaocheng, 2016-12-01 09:18:27]

PTAL.

[yosin_UTC9, 2016-12-01 09:41:43]

C++ changes are fine.
Could you improve layout tests? m(_ _)m

https://codereview.chromium.org/2541163003/diff/20001/third_party/WebKit/Layo...
File
third_party/WebKit/LayoutTests/editing/selection/extend-by-word-002-expected.txt
(right):

https://codereview.chromium.org/2541163003/diff/20001/third_party/WebKit/Layo...
third_party/WebKit/LayoutTests/editing/selection/extend-by-word-002-expected.txt:4:
PASS selection.focusNode is $("test").querySelectorAll("li a")[3].firstChild
Could you convert this test to assert_selection() for ease of expectation
changes?

https://codereview.chromium.org/2541163003/diff/20001/third_party/WebKit/Layo...
File third_party/WebKit/LayoutTests/editing/selection/extend-by-word-002.html
(right):

https://codereview.chromium.org/2541163003/diff/20001/third_party/WebKit/Layo...
third_party/WebKit/LayoutTests/editing/selection/extend-by-word-002.html:55: if
(window.internals)
Could you convert this test to assert_selection() for ease of expectation
changes?

https://codereview.chromium.org/2541163003/diff/20001/third_party/WebKit/Layo...
File
third_party/WebKit/LayoutTests/editing/text-iterator/first-letter-word-boundary-expected.txt
(right):

https://codereview.chromium.org/2541163003/diff/20001/third_party/WebKit/Layo...
third_party/WebKit/LayoutTests/editing/text-iterator/first-letter-word-boundary-expected.txt:4:
white-space: normal;
Could you convert this test to assert_selection() for ease of expectation
changes?

https://codereview.chromium.org/2541163003/diff/20001/third_party/WebKit/Sour...
File third_party/WebKit/Source/core/editing/iterators/TextIterator.cpp (right):

https://codereview.chromium.org/2541163003/diff/20001/third_party/WebKit/Sour...
third_party/WebKit/Source/core/editing/iterators/TextIterator.cpp:227: if
(m_node != m_startContainer)
nit: return m_node == m_startContainer;
as simplified if-statement.

https://codereview.chromium.org/2541163003/diff/20001/third_party/WebKit/Sour...
File third_party/WebKit/Source/core/editing/iterators/TextIterator.h (right):

https://codereview.chromium.org/2541163003/diff/20001/third_party/WebKit/Sour...
third_party/WebKit/Source/core/editing/iterators/TextIterator.h:141: bool
prepareForFirstLetterInitialization();
Could you add a comment to explain what |bool| result is?

[Xiaocheng, 2016-12-01 10:09:56]

I think it's better to convert the two tests in separate patches after this one
lands. As the two tests currently fail, it seems a little bit weird to convert
them assert_selection together with FAIL expectations...

https://codereview.chromium.org/2541163003/diff/20001/third_party/WebKit/Sour...
File third_party/WebKit/Source/core/editing/iterators/TextIterator.cpp (right):

https://codereview.chromium.org/2541163003/diff/20001/third_party/WebKit/Sour...
third_party/WebKit/Source/core/editing/iterators/TextIterator.cpp:227: if
(m_node != m_startContainer)
On 2016/12/01 at 09:41:42, Yosi_UTC9 wrote:
> nit: return m_node == m_startContainer;
> as simplified if-statement.

Done.

https://codereview.chromium.org/2541163003/diff/20001/third_party/WebKit/Sour...
File third_party/WebKit/Source/core/editing/iterators/TextIterator.h (right):

https://codereview.chromium.org/2541163003/diff/20001/third_party/WebKit/Sour...
third_party/WebKit/Source/core/editing/iterators/TextIterator.h:141: bool
prepareForFirstLetterInitialization();
On 2016/12/01 at 09:41:42, Yosi_UTC9 wrote:
> Could you add a comment to explain what |bool| result is?

Done.

[Xiaocheng, 2016-12-01 10:10:12]

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

[commit-bot: I haz the power, 2016-12-01 10:10:24]

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, 2016-12-01 11:16:12]

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

[commit-bot: I haz the power, 2016-12-01 11:16:13]

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

[Xiaocheng, 2016-12-05 06:45:06]

Description was changed from

==========
Fix TextIterator's behavior with first-letter

TextIterator's behavior with first-letter is broken:
1. If its starts in a text node with first-letter and the starting
offset is non-zero, wrong text is passed to its text state.
2. When the text state is handling the remaining text of first-letter,
it doesn't consider the length of first-letter, and hence, reports
wrong offsets of the current text.

To fix 2, this patch makes the text state remember the length of
first-letter, and use it to adjust the output of
start/endOffsetInCurrentContainer.

To fix 1, given that the current behavior is correct when we start in
a text node at offset 0 (even with first-letter), this patch performs
a reduction that:
- start iterating with offset 0 instead of the given start offset
- have extra calls of |advance()| during initialization so that we have
moved to the given start position when initialization ends
- adjust text run start and end offsets when emitting text of the starting
text node

This patch also corrects the behavior in two layout tests:
- editing/selection/extend-by-word-002.html
- editing/text-iterator/first-letter-word-boundary.html

This patch is not an ultimate fix of TextIterator's behavior with
first-letter, but more like a first-aid hack built upon the current design.
In the long term, we should rewrite TextIterator.

BUG=647080
==========

to

==========
Fix TextIterator's behavior with first-letter

TextIterator's behavior with first-letter is broken:
1. If its starts in a text node with first-letter and the starting
offset is non-zero, wrong text is passed to its text state.
2. When the text state is handling the remaining text of first-letter,
it doesn't consider the length of first-letter, and hence, reports
wrong offsets of the current text.

To fix 2, this patch makes the text state remember the length of
first-letter, and use it to adjust the output of
start/endOffsetInCurrentContainer.

To fix 1, given that the current behavior is correct when we start in
a text node at offset 0 (even with first-letter), this patch performs
a reduction that:
- start iterating with offset 0 instead of the given start offset
- have extra calls of |advance()| during initialization so that we have
moved to the given start position when initialization ends
- adjust text run start and end offsets when emitting text of the starting
text node

This patch partially corrects the behavior in two layout tests:
- editing/selection/extend-by-word-002.html
- editing/text-iterator/first-letter-word-boundary.html
The tests are still failing for other reasons, see crbug.com/671104

This patch is not an ultimate fix of TextIterator's behavior with
first-letter, but more like a first-aid hack built upon the current design.
In the long term, we should rewrite TextIterator.

BUG=647080
==========

[Xiaocheng, 2016-12-05 06:47:20]

The CQ bit was checked by xiaochengh@chromium.org

[commit-bot: I haz the power, 2016-12-05 06:47:39]

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, 2016-12-05 06:47:39]

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

[commit-bot: I haz the power, 2016-12-05 06:47:42]

No L-G-T-M from a valid reviewer yet. 
CQ run can only be started by full committers or once the patch has
received an L-G-T-M from a full committer.
Even if an L-G-T-M may have been provided, it was from a non-committer,
_not_ a full super star committer.
See http://www.chromium.org/getting-involved/become-a-committer
Note that this has nothing to do with OWNERS files.

[Xiaocheng, 2016-12-05 06:54:49]

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

[commit-bot: I haz the power, 2016-12-05 06:55:00]

Dry run: CQ is trying da patch. Follow status at
 
https://chromium-cq-status.appspot.com/v2/patch-status/codereview.chromium.or...

[Xiaocheng, 2016-12-05 08:23:33]

xiaochengh@chromium.org changed reviewers:
+ tkent@chromium.org

[Xiaocheng, 2016-12-05 08:23:34]

PTAL, as yosin@ is OOO...

[tkent, 2016-12-05 08:42:47]

yosin@ already said "fine".  So I reviewed only cosmetic stuff of the code.

https://codereview.chromium.org/2541163003/diff/60001/third_party/WebKit/Sour...
File third_party/WebKit/Source/core/editing/iterators/TextIterator.cpp (right):

https://codereview.chromium.org/2541163003/diff/60001/third_party/WebKit/Sour...
third_party/WebKit/Source/core/editing/iterators/TextIterator.cpp:1208: Node*
textNode,
Can we make it |const Node*| or |const Node&|?

https://codereview.chromium.org/2541163003/diff/60001/third_party/WebKit/Sour...
third_party/WebKit/Source/core/editing/iterators/TextIterator.cpp:1209:
LayoutText* layoutObject,
Can we make it |const LayoutText*| or |const LayoutText&|?

https://codereview.chromium.org/2541163003/diff/60001/third_party/WebKit/Sour...
third_party/WebKit/Source/core/editing/iterators/TextIterator.cpp:1229: Node*
textNode,
Can we make it |const Node*| or |const Node&|?

https://codereview.chromium.org/2541163003/diff/60001/third_party/WebKit/Sour...
third_party/WebKit/Source/core/editing/iterators/TextIterator.cpp:1230:
LayoutText* layoutObject,
Can we make it |const LayoutText*| or |const LayoutText&|?

[commit-bot: I haz the power, 2016-12-05 08:49:39]

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

[commit-bot: I haz the power, 2016-12-05 08:49:40]

Dry run: This issue passed the CQ dry run.

[Xiaocheng, 2016-12-05 09:01:16]

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

[commit-bot: I haz the power, 2016-12-05 09:01:53]

Dry run: CQ is trying da patch. Follow status at
 
https://chromium-cq-status.appspot.com/v2/patch-status/codereview.chromium.or...

[Xiaocheng, 2016-12-05 09:02:43]

https://codereview.chromium.org/2541163003/diff/60001/third_party/WebKit/Sour...
File third_party/WebKit/Source/core/editing/iterators/TextIterator.cpp (right):

https://codereview.chromium.org/2541163003/diff/60001/third_party/WebKit/Sour...
third_party/WebKit/Source/core/editing/iterators/TextIterator.cpp:1208: Node*
textNode,
On 2016/12/05 at 08:42:47, tkent wrote:
> Can we make it |const Node*| or |const Node&|?

Changed to |const Node&|.

https://codereview.chromium.org/2541163003/diff/60001/third_party/WebKit/Sour...
third_party/WebKit/Source/core/editing/iterators/TextIterator.cpp:1209:
LayoutText* layoutObject,
On 2016/12/05 at 08:42:47, tkent wrote:
> Can we make it |const LayoutText*| or |const LayoutText&|?

Changed to |const LayoutText&|.

https://codereview.chromium.org/2541163003/diff/60001/third_party/WebKit/Sour...
third_party/WebKit/Source/core/editing/iterators/TextIterator.cpp:1229: Node*
textNode,
On 2016/12/05 at 08:42:47, tkent wrote:
> Can we make it |const Node*| or |const Node&|?

Changed to |const Node&|.

https://codereview.chromium.org/2541163003/diff/60001/third_party/WebKit/Sour...
third_party/WebKit/Source/core/editing/iterators/TextIterator.cpp:1230:
LayoutText* layoutObject,
On 2016/12/05 at 08:42:47, tkent wrote:
> Can we make it |const LayoutText*| or |const LayoutText&|?

Changed to |const LayoutText&|.

[tkent, 2016-12-05 09:04:19]

rs lgtm

[Xiaocheng, 2016-12-05 09:07:39]

The CQ bit was unchecked by xiaochengh@chromium.org

[Xiaocheng, 2016-12-05 09:07:47]

The CQ bit was checked by xiaochengh@chromium.org

[Xiaocheng, 2016-12-05 09:07:48]

Thanks for the review!

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

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, 2016-12-05 10:39:04]

CQ is committing da patch.

Bot data: {"patchset_id": 80001, "attempt_start_ts": 1480928867846710,
"parent_rev": "53ad122bb044f9b52a3c8bba1a611b20a15e0378", "commit_rev":
"251c42a9405ab87378d9c850fd5b95e9c1063531"}

[commit-bot: I haz the power, 2016-12-05 10:39:31]

Committed patchset #5 (id:80001)

[commit-bot: I haz the power, 2016-12-05 10:43:13]

Description was changed from

==========
Fix TextIterator's behavior with first-letter

TextIterator's behavior with first-letter is broken:
1. If its starts in a text node with first-letter and the starting
offset is non-zero, wrong text is passed to its text state.
2. When the text state is handling the remaining text of first-letter,
it doesn't consider the length of first-letter, and hence, reports
wrong offsets of the current text.

To fix 2, this patch makes the text state remember the length of
first-letter, and use it to adjust the output of
start/endOffsetInCurrentContainer.

To fix 1, given that the current behavior is correct when we start in
a text node at offset 0 (even with first-letter), this patch performs
a reduction that:
- start iterating with offset 0 instead of the given start offset
- have extra calls of |advance()| during initialization so that we have
moved to the given start position when initialization ends
- adjust text run start and end offsets when emitting text of the starting
text node

This patch partially corrects the behavior in two layout tests:
- editing/selection/extend-by-word-002.html
- editing/text-iterator/first-letter-word-boundary.html
The tests are still failing for other reasons, see crbug.com/671104

This patch is not an ultimate fix of TextIterator's behavior with
first-letter, but more like a first-aid hack built upon the current design.
In the long term, we should rewrite TextIterator.

BUG=647080
==========

to

==========
Fix TextIterator's behavior with first-letter

TextIterator's behavior with first-letter is broken:
1. If its starts in a text node with first-letter and the starting
offset is non-zero, wrong text is passed to its text state.
2. When the text state is handling the remaining text of first-letter,
it doesn't consider the length of first-letter, and hence, reports
wrong offsets of the current text.

To fix 2, this patch makes the text state remember the length of
first-letter, and use it to adjust the output of
start/endOffsetInCurrentContainer.

To fix 1, given that the current behavior is correct when we start in
a text node at offset 0 (even with first-letter), this patch performs
a reduction that:
- start iterating with offset 0 instead of the given start offset
- have extra calls of |advance()| during initialization so that we have
moved to the given start position when initialization ends
- adjust text run start and end offsets when emitting text of the starting
text node

This patch partially corrects the behavior in two layout tests:
- editing/selection/extend-by-word-002.html
- editing/text-iterator/first-letter-word-boundary.html
The tests are still failing for other reasons, see crbug.com/671104

This patch is not an ultimate fix of TextIterator's behavior with
first-letter, but more like a first-aid hack built upon the current design.
In the long term, we should rewrite TextIterator.

BUG=647080

Committed: https://crrev.com/5185769b9ba7e9239d68c7dc672a27dd19b1685f
Cr-Commit-Position: refs/heads/master@{#436255}
==========

[commit-bot: I haz the power, 2016-12-05 10:43:14]

Patchset 5 (id:??) landed as
https://crrev.com/5185769b9ba7e9239d68c7dc672a27dd19b1685f
Cr-Commit-Position: refs/heads/master@{#436255}