Reland: Ntp: restore scroll position.

Reland: Ntp: restore scroll position.

* The scroll position is stored as extra data on the NavigationEntry.
* The main use case handled is when the user clicks on a suggested
article and then back to view more suggestions. Maintaining scroll position helps maintain context and flow here.
* It is the RecyclerView Adapter position that is stored and restored, so if the device is rotated in the meantime, scroll restore will still present the same content as long as the underlying data has not changed.
* Because the underlying data is subject to change a few times per day, the scroll position is not persisted. It would be confusing the restore to an old position that now shows different content.

BUG=606356
TBR=clamy,bauerb,tedchoc
CQ_INCLUDE_TRYBOTS=master.tryserver.chromium.linux:linux_site_isolation

Committed: https://crrev.com/22b18a9a6d4f421ddb6d4f74280a571bf7dca4f6
Cr-Commit-Position: refs/heads/master@{#420075}

patch from issue 2327083002 at patchset 160001 (http://crrev.com/2327083002#ps160001)

Committed: https://crrev.com/2c78ced6c8ce46eec8c9f7100b14b3414b7cbc07
Committed: https://crrev.com/5b1519e7304f1a6d2f1c3e50c2d8a933e21f2806
Cr-Original-Commit-Position: refs/heads/master@{#420896}
Cr-Commit-Position: refs/heads/master@{#421223}

[Michael van Ouwerkerk, 2016-09-26 13:17:11]

mvanouwerkerk@chromium.org changed reviewers:
+ bauerb@chromium.org, clamy@chromium.org, tedchoc@chromium.org

[Michael van Ouwerkerk, 2016-09-26 13:17:12]

This is a reland of https://codereview.chromium.org/2327083002. The diff is
between patch set 1 and 2.

I will TBR the previous reviewers, as the diff is minimal.

[Michael van Ouwerkerk, 2016-09-26 13:17:32]

Description was changed from

==========
Reland: Ntp: restore scroll position.

* The scroll position is stored as extra data on the NavigationEntry.
* The main use case handled is when the user clicks on a suggested
article and then back to view more suggestions. Maintaining scroll position
helps maintain context and flow here.
* It is the RecyclerView Adapter position that is stored and restored, so if the
device is rotated in the meantime, scroll restore will still present the same
content as long as the underlying data has not changed.
* Because the underlying data is subject to change a few times per day, the
scroll position is not persisted. It would be confusing the restore to an old
position that now shows different content.

BUG=606356
CQ_INCLUDE_TRYBOTS=master.tryserver.chromium.linux:linux_site_isolation

Committed: https://crrev.com/22b18a9a6d4f421ddb6d4f74280a571bf7dca4f6
Cr-Commit-Position: refs/heads/master@{#420075}

patch from issue 2327083002 at patchset 160001
(http://crrev.com/2327083002#ps160001)
==========

to

==========
Reland: Ntp: restore scroll position.

* The scroll position is stored as extra data on the NavigationEntry.
* The main use case handled is when the user clicks on a suggested
article and then back to view more suggestions. Maintaining scroll position
helps maintain context and flow here.
* It is the RecyclerView Adapter position that is stored and restored, so if the
device is rotated in the meantime, scroll restore will still present the same
content as long as the underlying data has not changed.
* Because the underlying data is subject to change a few times per day, the
scroll position is not persisted. It would be confusing the restore to an old
position that now shows different content.

BUG=606356
TBR=clamy,bauerb,tedchoc
CQ_INCLUDE_TRYBOTS=master.tryserver.chromium.linux:linux_site_isolation

Committed: https://crrev.com/22b18a9a6d4f421ddb6d4f74280a571bf7dca4f6
Cr-Commit-Position: refs/heads/master@{#420075}

patch from issue 2327083002 at patchset 160001
(http://crrev.com/2327083002#ps160001)
==========

[Michael van Ouwerkerk, 2016-09-26 13:17:47]

The CQ bit was checked by mvanouwerkerk@chromium.org

[commit-bot: I haz the power, 2016-09-26 13:18:05]

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

[Bernhard Bauer, 2016-09-26 13:49:23]

lgtm

[commit-bot: I haz the power, 2016-09-26 15:53:50]

Description was changed from

==========
Reland: Ntp: restore scroll position.

* The scroll position is stored as extra data on the NavigationEntry.
* The main use case handled is when the user clicks on a suggested
article and then back to view more suggestions. Maintaining scroll position
helps maintain context and flow here.
* It is the RecyclerView Adapter position that is stored and restored, so if the
device is rotated in the meantime, scroll restore will still present the same
content as long as the underlying data has not changed.
* Because the underlying data is subject to change a few times per day, the
scroll position is not persisted. It would be confusing the restore to an old
position that now shows different content.

BUG=606356
TBR=clamy,bauerb,tedchoc
CQ_INCLUDE_TRYBOTS=master.tryserver.chromium.linux:linux_site_isolation

Committed: https://crrev.com/22b18a9a6d4f421ddb6d4f74280a571bf7dca4f6
Cr-Commit-Position: refs/heads/master@{#420075}

patch from issue 2327083002 at patchset 160001
(http://crrev.com/2327083002#ps160001)
==========

to

==========
Reland: Ntp: restore scroll position.

* The scroll position is stored as extra data on the NavigationEntry.
* The main use case handled is when the user clicks on a suggested
article and then back to view more suggestions. Maintaining scroll position
helps maintain context and flow here.
* It is the RecyclerView Adapter position that is stored and restored, so if the
device is rotated in the meantime, scroll restore will still present the same
content as long as the underlying data has not changed.
* Because the underlying data is subject to change a few times per day, the
scroll position is not persisted. It would be confusing the restore to an old
position that now shows different content.

BUG=606356
TBR=clamy,bauerb,tedchoc
CQ_INCLUDE_TRYBOTS=master.tryserver.chromium.linux:linux_site_isolation

Committed: https://crrev.com/22b18a9a6d4f421ddb6d4f74280a571bf7dca4f6
Cr-Commit-Position: refs/heads/master@{#420075}

patch from issue 2327083002 at patchset 160001
(http://crrev.com/2327083002#ps160001)
==========

[commit-bot: I haz the power, 2016-09-26 15:53:53]

Committed patchset #2 (id:20001)

[commit-bot: I haz the power, 2016-09-26 15:57:55]

Description was changed from

==========
Reland: Ntp: restore scroll position.

* The scroll position is stored as extra data on the NavigationEntry.
* The main use case handled is when the user clicks on a suggested
article and then back to view more suggestions. Maintaining scroll position
helps maintain context and flow here.
* It is the RecyclerView Adapter position that is stored and restored, so if the
device is rotated in the meantime, scroll restore will still present the same
content as long as the underlying data has not changed.
* Because the underlying data is subject to change a few times per day, the
scroll position is not persisted. It would be confusing the restore to an old
position that now shows different content.

BUG=606356
TBR=clamy,bauerb,tedchoc
CQ_INCLUDE_TRYBOTS=master.tryserver.chromium.linux:linux_site_isolation

Committed: https://crrev.com/22b18a9a6d4f421ddb6d4f74280a571bf7dca4f6
Cr-Commit-Position: refs/heads/master@{#420075}

patch from issue 2327083002 at patchset 160001
(http://crrev.com/2327083002#ps160001)
==========

to

==========
Reland: Ntp: restore scroll position.

* The scroll position is stored as extra data on the NavigationEntry.
* The main use case handled is when the user clicks on a suggested
article and then back to view more suggestions. Maintaining scroll position
helps maintain context and flow here.
* It is the RecyclerView Adapter position that is stored and restored, so if the
device is rotated in the meantime, scroll restore will still present the same
content as long as the underlying data has not changed.
* Because the underlying data is subject to change a few times per day, the
scroll position is not persisted. It would be confusing the restore to an old
position that now shows different content.

BUG=606356
TBR=clamy,bauerb,tedchoc
CQ_INCLUDE_TRYBOTS=master.tryserver.chromium.linux:linux_site_isolation

Committed: https://crrev.com/22b18a9a6d4f421ddb6d4f74280a571bf7dca4f6
Cr-Commit-Position: refs/heads/master@{#420075}

patch from issue 2327083002 at patchset 160001
(http://crrev.com/2327083002#ps160001)

Committed: https://crrev.com/2c78ced6c8ce46eec8c9f7100b14b3414b7cbc07
Cr-Commit-Position: refs/heads/master@{#420896}
==========

[commit-bot: I haz the power, 2016-09-26 15:57:57]

Patchset 2 (id:??) landed as
https://crrev.com/2c78ced6c8ce46eec8c9f7100b14b3414b7cbc07
Cr-Commit-Position: refs/heads/master@{#420896}

[Ted C, 2016-09-26 18:40:26]

https://codereview.chromium.org/2365313002/diff/20001/chrome/android/java/src...
File chrome/android/java/src/org/chromium/chrome/browser/ntp/NewTabPage.java
(right):

https://codereview.chromium.org/2365313002/diff/20001/chrome/android/java/src...
chrome/android/java/src/org/chromium/chrome/browser/ntp/NewTabPage.java:878: if
(scrollPositionData == null) return RecyclerView.NO_POSITION;
I was testing locally and got this stack:
W/cr_NewTabPage(28076): Bad data found for scroll position: 
W/cr_NewTabPage(28076): java.lang.NumberFormatException: Invalid int: ""
W/cr_NewTabPage(28076): 	at java.lang.Integer.invalidInt(Integer.java:138)
W/cr_NewTabPage(28076): 	at java.lang.Integer.parseInt(Integer.java:358)
W/cr_NewTabPage(28076): 	at java.lang.Integer.parseInt(Integer.java:334)
W/cr_NewTabPage(28076): 	at
org.chromium.chrome.browser.ntp.NewTabPage.getScrollPositionFromNavigationEntry(NewTabPage.java:881)
W/cr_NewTabPage(28076): 	at
org.chromium.chrome.browser.ntp.NewTabPage.<init>(NewTabPage.java:705)
W/cr_NewTabPage(28076): 	at
org.chromium.chrome.browser.ntp.NativePageFactory.createNativePageForURL(NativePageFactory.java:4037)
W/cr_NewTabPage(28076): 	at
org.chromium.chrome.browser.tab.Tab.maybeShowNativePage(Tab.java:1968)
W/cr_NewTabPage(28076): 	at
org.chromium.chrome.browser.tab.Tab.handleDidCommitProvisonalLoadForFrame(Tab.java:1987)
W/cr_NewTabPage(28076): 	at
org.chromium.chrome.browser.tab.TabWebContentsObserver.didCommitProvisionalLoadForFrame(TabWebContentsObserver.java:234)
W/cr_NewTabPage(28076): 	at
org.chromium.content.browser.webcontents.WebContentsObserverProxy.didCommitProvisionalLoadForFrame(WebContentsObserverProxy.java:172)
W/cr_NewTabPage(28076): 	at
org.chromium.base.SystemMessageHandler.nativeDoRunLoopOnce(Native Method)
W/cr_NewTabPage(28076): 	at
org.chromium.base.SystemMessageHandler.handleMessage(SystemMessageHandler.java:41)
W/cr_NewTabPage(28076): 	at android.os.Handler.dispatchMessage(Handler.java:102)
W/cr_NewTabPage(28076): 	at android.os.Looper.loop(Looper.java:135)
W/cr_NewTabPage(28076): 	at
android.app.ActivityThread.main(ActivityThread.java:5254)
W/cr_NewTabPage(28076): 	at java.lang.reflect.Method.invoke(Native Method)
W/cr_NewTabPage(28076): 	at java.lang.reflect.Method.invoke(Method.java:372)
W/cr_NewTabPage(28076): 	at
com.android.internal.os.ZygoteInit$MethodAndArgsCaller.run(ZygoteInit.java:903)
W/cr_NewTabPage(28076): 	at
com.android.internal.os.ZygoteInit.main(ZygoteInit.java:698)

Should we use TextUtils.isEmpty here instead of == null?

[Khushal, 2016-09-26 19:33:32]

A revert of this CL (patchset #2 id:20001) has been created in
https://codereview.chromium.org/2370023002/ by khushalsagar@chromium.org.

The reason for reverting is: Breaks AndroidTests(Dbg:
https://build.chromium.org/p/chromium.linux/builders/Android%20Tests%20%28dbg....

[Michael van Ouwerkerk, 2016-09-27 14:36:58]

Ok I was finally able to reproduce the crash by enabling debug.assert on a pre-L
device, and address the issue. Sorry for the noise.

https://codereview.chromium.org/2365313002/diff/20001/chrome/android/java/src...
File chrome/android/java/src/org/chromium/chrome/browser/ntp/NewTabPage.java
(right):

https://codereview.chromium.org/2365313002/diff/20001/chrome/android/java/src...
chrome/android/java/src/org/chromium/chrome/browser/ntp/NewTabPage.java:878: if
(scrollPositionData == null) return RecyclerView.NO_POSITION;
On 2016/09/26 18:40:26, Ted C wrote:
> I was testing locally and got this stack:
> W/cr_NewTabPage(28076): Bad data found for scroll position: 
> W/cr_NewTabPage(28076): java.lang.NumberFormatException: Invalid int: ""
> W/cr_NewTabPage(28076): 	at java.lang.Integer.invalidInt(Integer.java:138)
> W/cr_NewTabPage(28076): 	at java.lang.Integer.parseInt(Integer.java:358)
> W/cr_NewTabPage(28076): 	at java.lang.Integer.parseInt(Integer.java:334)
> W/cr_NewTabPage(28076): 	at
>
org.chromium.chrome.browser.ntp.NewTabPage.getScrollPositionFromNavigationEntry(NewTabPage.java:881)
> W/cr_NewTabPage(28076): 	at
> org.chromium.chrome.browser.ntp.NewTabPage.<init>(NewTabPage.java:705)
> W/cr_NewTabPage(28076): 	at
>
org.chromium.chrome.browser.ntp.NativePageFactory.createNativePageForURL(NativePageFactory.java:4037)
> W/cr_NewTabPage(28076): 	at
> org.chromium.chrome.browser.tab.Tab.maybeShowNativePage(Tab.java:1968)
> W/cr_NewTabPage(28076): 	at
>
org.chromium.chrome.browser.tab.Tab.handleDidCommitProvisonalLoadForFrame(Tab.java:1987)
> W/cr_NewTabPage(28076): 	at
>
org.chromium.chrome.browser.tab.TabWebContentsObserver.didCommitProvisionalLoadForFrame(TabWebContentsObserver.java:234)
> W/cr_NewTabPage(28076): 	at
>
org.chromium.content.browser.webcontents.WebContentsObserverProxy.didCommitProvisionalLoadForFrame(WebContentsObserverProxy.java:172)
> W/cr_NewTabPage(28076): 	at
> org.chromium.base.SystemMessageHandler.nativeDoRunLoopOnce(Native Method)
> W/cr_NewTabPage(28076): 	at
>
org.chromium.base.SystemMessageHandler.handleMessage(SystemMessageHandler.java:41)
> W/cr_NewTabPage(28076): 	at
android.os.Handler.dispatchMessage(Handler.java:102)
> W/cr_NewTabPage(28076): 	at android.os.Looper.loop(Looper.java:135)
> W/cr_NewTabPage(28076): 	at
> android.app.ActivityThread.main(ActivityThread.java:5254)
> W/cr_NewTabPage(28076): 	at java.lang.reflect.Method.invoke(Native Method)
> W/cr_NewTabPage(28076): 	at java.lang.reflect.Method.invoke(Method.java:372)
> W/cr_NewTabPage(28076): 	at
>
com.android.internal.os.ZygoteInit$MethodAndArgsCaller.run(ZygoteInit.java:903)
> W/cr_NewTabPage(28076): 	at
> com.android.internal.os.ZygoteInit.main(ZygoteInit.java:698)
> 
> Should we use TextUtils.isEmpty here instead of == null?

Agreed, done.

[Michael van Ouwerkerk, 2016-09-27 14:37:17]

Description was changed from

==========
Reland: Ntp: restore scroll position.

* The scroll position is stored as extra data on the NavigationEntry.
* The main use case handled is when the user clicks on a suggested
article and then back to view more suggestions. Maintaining scroll position
helps maintain context and flow here.
* It is the RecyclerView Adapter position that is stored and restored, so if the
device is rotated in the meantime, scroll restore will still present the same
content as long as the underlying data has not changed.
* Because the underlying data is subject to change a few times per day, the
scroll position is not persisted. It would be confusing the restore to an old
position that now shows different content.

BUG=606356
TBR=clamy,bauerb,tedchoc
CQ_INCLUDE_TRYBOTS=master.tryserver.chromium.linux:linux_site_isolation

Committed: https://crrev.com/22b18a9a6d4f421ddb6d4f74280a571bf7dca4f6
Cr-Commit-Position: refs/heads/master@{#420075}

patch from issue 2327083002 at patchset 160001
(http://crrev.com/2327083002#ps160001)

Committed: https://crrev.com/2c78ced6c8ce46eec8c9f7100b14b3414b7cbc07
Cr-Commit-Position: refs/heads/master@{#420896}
==========

to

==========
Reland: Ntp: restore scroll position.

* The scroll position is stored as extra data on the NavigationEntry.
* The main use case handled is when the user clicks on a suggested
article and then back to view more suggestions. Maintaining scroll position
helps maintain context and flow here.
* It is the RecyclerView Adapter position that is stored and restored, so if the
device is rotated in the meantime, scroll restore will still present the same
content as long as the underlying data has not changed.
* Because the underlying data is subject to change a few times per day, the
scroll position is not persisted. It would be confusing the restore to an old
position that now shows different content.

BUG=606356
TBR=clamy,bauerb,tedchoc
CQ_INCLUDE_TRYBOTS=master.tryserver.chromium.linux:linux_site_isolation

Committed: https://crrev.com/22b18a9a6d4f421ddb6d4f74280a571bf7dca4f6
Cr-Commit-Position: refs/heads/master@{#420075}

patch from issue 2327083002 at patchset 160001
(http://crrev.com/2327083002#ps160001)

Committed: https://crrev.com/2c78ced6c8ce46eec8c9f7100b14b3414b7cbc07
Cr-Commit-Position: refs/heads/master@{#420896}
==========

[Michael van Ouwerkerk, 2016-09-27 14:37:39]

The CQ bit was checked by mvanouwerkerk@chromium.org

[Michael van Ouwerkerk, 2016-09-27 14:37:39]

The patchset sent to the CQ was uploaded after l-g-t-m from bauerb@chromium.org
Link to the patchset: https://codereview.chromium.org/2365313002/#ps40001
(title: "Do not run Java assert, it really just happens sometimes.")

[commit-bot: I haz the power, 2016-09-27 14:38:00]

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-09-27 14:40:27]

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

[commit-bot: I haz the power, 2016-09-27 14:40:28]

Try jobs failed on following builders:
  ios-simulator on master.tryserver.chromium.mac (JOB_FAILED,
http://build.chromium.org/p/tryserver.chromium.mac/builders/ios-simulator/bui...)
  mac_chromium_compile_dbg_ng on master.tryserver.chromium.mac (JOB_FAILED,
http://build.chromium.org/p/tryserver.chromium.mac/builders/mac_chromium_comp...)

[Michael van Ouwerkerk, 2016-09-27 15:13:20]

The CQ bit was checked by mvanouwerkerk@chromium.org

[Michael van Ouwerkerk, 2016-09-27 15:13:21]

The patchset sent to the CQ was uploaded after l-g-t-m from bauerb@chromium.org
Link to the patchset: https://codereview.chromium.org/2365313002/#ps60001
(title: "Rebase.")

[commit-bot: I haz the power, 2016-09-27 15:13:43]

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-09-27 15:48:05]

Description was changed from

==========
Reland: Ntp: restore scroll position.

* The scroll position is stored as extra data on the NavigationEntry.
* The main use case handled is when the user clicks on a suggested
article and then back to view more suggestions. Maintaining scroll position
helps maintain context and flow here.
* It is the RecyclerView Adapter position that is stored and restored, so if the
device is rotated in the meantime, scroll restore will still present the same
content as long as the underlying data has not changed.
* Because the underlying data is subject to change a few times per day, the
scroll position is not persisted. It would be confusing the restore to an old
position that now shows different content.

BUG=606356
TBR=clamy,bauerb,tedchoc
CQ_INCLUDE_TRYBOTS=master.tryserver.chromium.linux:linux_site_isolation

Committed: https://crrev.com/22b18a9a6d4f421ddb6d4f74280a571bf7dca4f6
Cr-Commit-Position: refs/heads/master@{#420075}

patch from issue 2327083002 at patchset 160001
(http://crrev.com/2327083002#ps160001)

Committed: https://crrev.com/2c78ced6c8ce46eec8c9f7100b14b3414b7cbc07
Cr-Commit-Position: refs/heads/master@{#420896}
==========

to

==========
Reland: Ntp: restore scroll position.

* The scroll position is stored as extra data on the NavigationEntry.
* The main use case handled is when the user clicks on a suggested
article and then back to view more suggestions. Maintaining scroll position
helps maintain context and flow here.
* It is the RecyclerView Adapter position that is stored and restored, so if the
device is rotated in the meantime, scroll restore will still present the same
content as long as the underlying data has not changed.
* Because the underlying data is subject to change a few times per day, the
scroll position is not persisted. It would be confusing the restore to an old
position that now shows different content.

BUG=606356
TBR=clamy,bauerb,tedchoc
CQ_INCLUDE_TRYBOTS=master.tryserver.chromium.linux:linux_site_isolation

Committed: https://crrev.com/22b18a9a6d4f421ddb6d4f74280a571bf7dca4f6
Cr-Commit-Position: refs/heads/master@{#420075}

patch from issue 2327083002 at patchset 160001
(http://crrev.com/2327083002#ps160001)

Committed: https://crrev.com/2c78ced6c8ce46eec8c9f7100b14b3414b7cbc07
Cr-Commit-Position: refs/heads/master@{#420896}
==========

[commit-bot: I haz the power, 2016-09-27 15:48:06]

Committed patchset #4 (id:60001)

[commit-bot: I haz the power, 2016-09-27 15:52:02]

Description was changed from

==========
Reland: Ntp: restore scroll position.

* The scroll position is stored as extra data on the NavigationEntry.
* The main use case handled is when the user clicks on a suggested
article and then back to view more suggestions. Maintaining scroll position
helps maintain context and flow here.
* It is the RecyclerView Adapter position that is stored and restored, so if the
device is rotated in the meantime, scroll restore will still present the same
content as long as the underlying data has not changed.
* Because the underlying data is subject to change a few times per day, the
scroll position is not persisted. It would be confusing the restore to an old
position that now shows different content.

BUG=606356
TBR=clamy,bauerb,tedchoc
CQ_INCLUDE_TRYBOTS=master.tryserver.chromium.linux:linux_site_isolation

Committed: https://crrev.com/22b18a9a6d4f421ddb6d4f74280a571bf7dca4f6
Cr-Commit-Position: refs/heads/master@{#420075}

patch from issue 2327083002 at patchset 160001
(http://crrev.com/2327083002#ps160001)

Committed: https://crrev.com/2c78ced6c8ce46eec8c9f7100b14b3414b7cbc07
Cr-Commit-Position: refs/heads/master@{#420896}
==========

to

==========
Reland: Ntp: restore scroll position.

* The scroll position is stored as extra data on the NavigationEntry.
* The main use case handled is when the user clicks on a suggested
article and then back to view more suggestions. Maintaining scroll position
helps maintain context and flow here.
* It is the RecyclerView Adapter position that is stored and restored, so if the
device is rotated in the meantime, scroll restore will still present the same
content as long as the underlying data has not changed.
* Because the underlying data is subject to change a few times per day, the
scroll position is not persisted. It would be confusing the restore to an old
position that now shows different content.

BUG=606356
TBR=clamy,bauerb,tedchoc
CQ_INCLUDE_TRYBOTS=master.tryserver.chromium.linux:linux_site_isolation

Committed: https://crrev.com/22b18a9a6d4f421ddb6d4f74280a571bf7dca4f6
Cr-Commit-Position: refs/heads/master@{#420075}

patch from issue 2327083002 at patchset 160001
(http://crrev.com/2327083002#ps160001)

Committed: https://crrev.com/2c78ced6c8ce46eec8c9f7100b14b3414b7cbc07
Committed: https://crrev.com/5b1519e7304f1a6d2f1c3e50c2d8a933e21f2806
Cr-Original-Commit-Position: refs/heads/master@{#420896}
Cr-Commit-Position: refs/heads/master@{#421223}
==========

[commit-bot: I haz the power, 2016-09-27 15:52:03]

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