[Android] Relanding Smart GO NEXT feature in Android Chrome 2/2

[Android] Relanding Smart GO NEXT feature in Android Chrome 2/2

This is second patch of Smart GO NEXT feature. Initial patch is
landed @ https://codereview.chromium.org/2967493002/

Design Document: https://docs.google.com/document/d/1h0diigZ8LUi7A3UKJ_zwNUbvNQoe-Nwr55_p6ivSPNg/edit?usp=sharing

Performance regression is getting tackled using the triggering of Focus Controller
call only if element which is in focus is an HTMLFormControl element.

BUG=410785, 648986, 733222, 737388

[AKVT, 2017-07-10 13:45:39]

ajith.v@samsung.com changed reviewers:
+ changwan@chromium.org, nasko@chromium.org, tkent@chromium.org

[AKVT, 2017-07-10 13:45:40]

changwan@ - PTAL content/public/android

nasko@ - PTAL content/ 

tkent@ - PTAL third_party/WebKit

kochi@ - PTAL WebViewTest.cpp and InputMethodController.cpp

[AKVT, 2017-07-10 13:45:41]

changwan@ - PTAL content/public/android

nasko@ - PTAL content/ 

tkent@ - PTAL third_party/WebKit

kochi@ - PTAL WebViewTest.cpp and InputMethodController.cpp

[AKVT, 2017-07-10 13:45:44]

changwan@ - PTAL content/public/android

nasko@ - PTAL content/ 

tkent@ - PTAL third_party/WebKit

kochi@ - PTAL WebViewTest.cpp and InputMethodController.cpp

[Changwan Ryu, 2017-07-10 17:04:54]

content/public/android LGTM

[AKVT, 2017-07-10 18:28:58]

Description was changed from

==========
[Android] Relanding Smart GO NEXT feature in Android Chrome 2/2

This is second patch of Smart GO NEXT feature. Initial patch is
landed @ https://codereview.chromium.org/2967493002/

Design Document:
https://docs.google.com/document/d/1h0diigZ8LUi7A3UKJ_zwNUbvNQoe-Nwr55_p6ivSP...

Performance regression is getting tackled using the triggering of focus
controller
call only during HTML form related element is getting focused.

BUG=410785,648986,733222,737388
==========

to

==========
[Android] Relanding Smart GO NEXT feature in Android Chrome 2/2

This is second patch of Smart GO NEXT feature. Initial patch is
landed @ https://codereview.chromium.org/2967493002/

Design Document:
https://docs.google.com/document/d/1h0diigZ8LUi7A3UKJ_zwNUbvNQoe-Nwr55_p6ivSP...

Performance regression is getting tackled using the triggering of Focus
Controller
call only if element which is in focus is an HTMLFormControl element.

BUG=410785,648986,733222,737388
==========

[AKVT, 2017-07-11 05:25:06]

ajith.v@samsung.com changed reviewers:
+ dcheng@chromium.org, kochi@chromium.org

[AKVT, 2017-07-11 05:26:26]

kochi@ - PTAL WebViewTest.cpp and InputMehodController.cpp

dcheng@ - PTAL content/ as nasko@ is OOO

tkent@ - PTAL third_party/WebKit changes.

[tkent, 2017-07-11 05:38:36]

> Performance regression is getting tackled using the triggering of Focus
Controller
> call only if element which is in focus is an HTMLFormControl element.

I don't think it's a right solution.  If a form control is focused, this CL will
regress performance, right?  A focused element is typically a form control in
real world web sites.

[AKVT, 2017-07-11 05:51:59]

On 2017/07/11 05:38:36, tkent wrote:
> > Performance regression is getting tackled using the triggering of Focus
> Controller
> > call only if element which is in focus is an HTMLFormControl element.
> 
> I don't think it's a right solution.  If a form control is focused, this CL
will
> regress performance, right?  A focused element is typically a form control in
> real world web sites.

But for calculating the next/previous element, we need this code to hit as well.
So I do not have a better solution right now. Also could you refer the benchmark
results generated as part of this patch.

[Takayoshi Kochi (Google), 2017-07-11 06:24:37]

On 2017/07/11 05:38:36, tkent wrote:
> > Performance regression is getting tackled using the triggering of Focus
> Controller
> > call only if element which is in focus is an HTMLFormControl element.
> 
> I don't think it's a right solution.  If a form control is focused, this CL
will
> regress performance, right?  A focused element is typically a form control in
> real world web sites.

I agree tkent's comment above.  Adding mine below...

The change in InputMethodController.cpp, makes that if the focus is at
contenteditable, it will not show next/prev button, is it an intended change?

IIRC in FocusController::NextFocusableElementInForm() tries to find
form control element or content editable which belongs to the same form.
So I think this change breaks the user expectation.


Another thing I have is that I'd guess the hypothesis for this
regression is that InputMethodController::TextInputFlags() is
called quite often, and doing heavy operation inside the function
makes some performance tests run slow.

So preventing regression for them is either (or both)
- make number of calls to TextInputFlags() fewer
- make NextFocusableElementInForm() blazing fast

So counting how many times TextInputFlags() is called during perf
benchmark and how much time spent in NextFocusableElementInForm()
would be the first step for fixing the issue.  If the calls are
quite small, or NextFocusableElementInForm() is already very fast,
then the hypothesis is wrong and you have to find another cause.
Even if the hypothesis is proven correct, there are several choices
for fixing those - so reviewers expect you to explain why the change
is the best solution you thought.

Did you see any progress in actual number, or you just
guessed enclosing calls with "If" would not get worse?

If you find the current change already fixed the perf regression,
please include the numbers (e.g. time change delta for specific
benchmark before and after) in the description so that all
reviewers can be assured that this change resolved the performance
issue.

I don't think this is not that hard to measure/compare how much time
spent with/without the new code for the benchmark.

[Takayoshi Kochi (Google), 2017-07-11 06:27:25]

On 2017/07/11 05:51:59, AKVT wrote:
> On 2017/07/11 05:38:36, tkent wrote:
> > > Performance regression is getting tackled using the triggering of Focus
> > Controller
> > > call only if element which is in focus is an HTMLFormControl element.
> > 
> > I don't think it's a right solution.  If a form control is focused, this CL
> will
> > regress performance, right?  A focused element is typically a form control
in
> > real world web sites.
> 
> But for calculating the next/previous element, we need this code to hit as
well.
> So I do not have a better solution right now. Also could you refer the
benchmark
> results generated as part of this patch.

Could you point which one to check?
I see lots of *_perf_bisect trybot runs...

[AKVT, 2017-07-11 06:30:18]

On 2017/07/11 06:27:25, Takayoshi Kochi (Google) wrote:
> On 2017/07/11 05:51:59, AKVT wrote:
> > On 2017/07/11 05:38:36, tkent wrote:
> > > > Performance regression is getting tackled using the triggering of Focus
> > > Controller
> > > > call only if element which is in focus is an HTMLFormControl element.
> > > 
> > > I don't think it's a right solution.  If a form control is focused, this
CL
> > will
> > > regress performance, right?  A focused element is typically a form control
> in
> > > real world web sites.
> > 
> > But for calculating the next/previous element, we need this code to hit as
> well.
> > So I do not have a better solution right now. Also could you refer the
> benchmark
> > results generated as part of this patch.
> 
> Could you point which one to check?
> I see lots of *_perf_bisect trybot runs...

Please see android_nexus7_perf_bisect

[Takayoshi Kochi (Google), 2017-07-11 06:43:44]

On 2017/07/11 06:30:18, AKVT wrote:
> On 2017/07/11 06:27:25, Takayoshi Kochi (Google) wrote:
> > On 2017/07/11 05:51:59, AKVT wrote:
> > > On 2017/07/11 05:38:36, tkent wrote:
> > > > > Performance regression is getting tackled using the triggering of
Focus
> > > > Controller
> > > > > call only if element which is in focus is an HTMLFormControl element.
> > > > 
> > > > I don't think it's a right solution.  If a form control is focused, this
> CL
> > > will
> > > > regress performance, right?  A focused element is typically a form
control
> > in
> > > > real world web sites.
> > > 
> > > But for calculating the next/previous element, we need this code to hit as
> > well.
> > > So I do not have a better solution right now. Also could you refer the
> > benchmark
> > > results generated as part of this patch.
> > 
> > Could you point which one to check?
> > I see lots of *_perf_bisect trybot runs...
> 
> Please see android_nexus7_perf_bisect

Hmm, I took a look at
https://build.chromium.org/p/tryserver.chromium.perf/builders/android_nexus7_...
but which benchmark result I should take a look?

[Takayoshi Kochi (Google), 2017-07-11 06:45:51]

On 2017/07/11 06:43:44, Takayoshi Kochi (Google) wrote:
> On 2017/07/11 06:30:18, AKVT wrote:
> > On 2017/07/11 06:27:25, Takayoshi Kochi (Google) wrote:
> > > On 2017/07/11 05:51:59, AKVT wrote:
> > > > On 2017/07/11 05:38:36, tkent wrote:
> > > > > > Performance regression is getting tackled using the triggering of
> Focus
> > > > > Controller
> > > > > > call only if element which is in focus is an HTMLFormControl
element.
> > > > > 
> > > > > I don't think it's a right solution.  If a form control is focused,
this
> > CL
> > > > will
> > > > > regress performance, right?  A focused element is typically a form
> control
> > > in
> > > > > real world web sites.
> > > > 
> > > > But for calculating the next/previous element, we need this code to hit
as
> > > well.
> > > > So I do not have a better solution right now. Also could you refer the
> > > benchmark
> > > > results generated as part of this patch.
> > > 
> > > Could you point which one to check?
> > > I see lots of *_perf_bisect trybot runs...
> > 
> > Please see android_nexus7_perf_bisect
> 
> Hmm, I took a look at
>
https://build.chromium.org/p/tryserver.chromium.perf/builders/android_nexus7_...
> but which benchmark result I should take a look?

(I tried to find something "system_health.common_desktop" but could not find)

[Takayoshi Kochi (Google), 2017-07-11 06:56:41]

On 2017/07/11 06:45:51, Takayoshi Kochi (Google) wrote:
> On 2017/07/11 06:43:44, Takayoshi Kochi (Google) wrote:
> > On 2017/07/11 06:30:18, AKVT wrote:
> > > On 2017/07/11 06:27:25, Takayoshi Kochi (Google) wrote:
> > > > On 2017/07/11 05:51:59, AKVT wrote:
> > > > > On 2017/07/11 05:38:36, tkent wrote:
> > > > > > > Performance regression is getting tackled using the triggering of
> > Focus
> > > > > > Controller
> > > > > > > call only if element which is in focus is an HTMLFormControl
> element.
> > > > > > 
> > > > > > I don't think it's a right solution.  If a form control is focused,
> this
> > > CL
> > > > > will
> > > > > > regress performance, right?  A focused element is typically a form
> > control
> > > > in
> > > > > > real world web sites.
> > > > > 
> > > > > But for calculating the next/previous element, we need this code to
hit
> as
> > > > well.
> > > > > So I do not have a better solution right now. Also could you refer the
> > > > benchmark
> > > > > results generated as part of this patch.
> > > > 
> > > > Could you point which one to check?
> > > > I see lots of *_perf_bisect trybot runs...
> > > 
> > > Please see android_nexus7_perf_bisect
> > 
> > Hmm, I took a look at
> >
>
https://build.chromium.org/p/tryserver.chromium.perf/builders/android_nexus7_...
> > but which benchmark result I should take a look?
> 
> (I tried to find something "system_health.common_desktop" but could not find)

Nevermind, I found it under cpu_time_percentage.

[Takayoshi Kochi (Google), 2017-07-11 07:24:08]

I took a look at mac_10_12_perf_bisect, which is same as the original report
in crbug.com/737388#c3.

Quoting the result from there:

> Bisect Details
>   Configuration: mac_10_12_perf_bisect
>   Benchmark    : system_health.common_desktop
>   Metric       :
cpu_time_percentage_avg/browse_social/browse_social_facebook_infinite_scroll
>   Change       : 34.27% | 0.472535769612 -> 0.634453614884

I interpret this as CPU usage % regressed from ~47% to ~63%.

And now I looked at
https://build.chromium.org/p/tryserver.chromium.perf/builders/mac_10_12_perf_...
(specifically "HTML Results", shortened URL is https://goo.gl/qWhrU8 ),
cpu_time_percentage grew from "avg 47.143%" (TOT) to "avg 62.689%" (Patch).

So I am not sure this CL fixed the perf regression on the reported issue.

But android_nexus7_perf_bisect says it's from 124.407% to 127.403%, which is
very marginal increase.

[AKVT, 2017-07-12 06:29:57]

On 2017/07/11 06:24:37, Takayoshi Kochi (Google) wrote:
> On 2017/07/11 05:38:36, tkent wrote:
> > > Performance regression is getting tackled using the triggering of Focus
> > Controller
> > > call only if element which is in focus is an HTMLFormControl element.
> > 
> > I don't think it's a right solution.  If a form control is focused, this CL
> will
> > regress performance, right?  A focused element is typically a form control
in
> > real world web sites.
> 
> I agree tkent's comment above.  Adding mine below...
> 
> The change in InputMethodController.cpp, makes that if the focus is at
> contenteditable, it will not show next/prev button, is it an intended change?
> 
> IIRC in FocusController::NextFocusableElementInForm() tries to find
> form control element or content editable which belongs to the same form.
> So I think this change breaks the user expectation.
> 
> 
> Another thing I have is that I'd guess the hypothesis for this
> regression is that InputMethodController::TextInputFlags() is
> called quite often, and doing heavy operation inside the function
> makes some performance tests run slow.
> 
> So preventing regression for them is either (or both)
> - make number of calls to TextInputFlags() fewer
> - make NextFocusableElementInForm() blazing fast
> 
> So counting how many times TextInputFlags() is called during perf
> benchmark and how much time spent in NextFocusableElementInForm()
> would be the first step for fixing the issue.  If the calls are
> quite small, or NextFocusableElementInForm() is already very fast,
> then the hypothesis is wrong and you have to find another cause.
> Even if the hypothesis is proven correct, there are several choices
> for fixing those - so reviewers expect you to explain why the change
> is the best solution you thought.
> 
> Did you see any progress in actual number, or you just
> guessed enclosing calls with "If" would not get worse?
> 
> If you find the current change already fixed the perf regression,
> please include the numbers (e.g. time change delta for specific
> benchmark before and after) in the description so that all
> reviewers can be assured that this change resolved the performance
> issue.
> 
> I don't think this is not that hard to measure/compare how much time
> spent with/without the new code for the benchmark.


With Patch https://codereview.chromium.org/2967493002/, no regression is
reported, which indicates calling NextFocusableElementInForm() from
TextInputFlags() is introducing the regression. Since I am running the tests on
trybot, I am not sure, how do I inspect my logs in it ?

> Even if the hypothesis is proven correct, there are several choices
> for fixing those - I didn't got your point correctly here.

[Takayoshi Kochi (Google), 2017-07-14 08:15:23]

On 2017/07/12 06:29:57, AKVT wrote:
> On 2017/07/11 06:24:37, Takayoshi Kochi (Google) wrote:
> > I don't think this is not that hard to measure/compare how much time
> > spent with/without the new code for the benchmark.
> 
> With Patch https://codereview.chromium.org/2967493002/, no regression is
> reported, which indicates calling NextFocusableElementInForm() from
> TextInputFlags() is introducing the regression. Since I am running the tests
on
> trybot, I am not sure, how do I inspect my logs in it ?

Can you run the test with your local machine and Android devices locally?
If so, you can tentatively have a call counter in TextInputFlags(), and
spit out debug log whenever it's called, or preferably at exit.

From the perf bot results, I saw general tendency that desktops bots regress
more
than android bots, though I'm not completely sure.  That may indicate that
the number of calls into TextInputFlags() during scrolling differ between
Androids and desktops.

This feature is currently Android-only, so regression on non-Android desktops is
never accepted.

[AKVT, 2017-07-14 08:32:23]

On 2017/07/14 08:15:23, Takayoshi Kochi (Google) wrote:
> On 2017/07/12 06:29:57, AKVT wrote:
> > On 2017/07/11 06:24:37, Takayoshi Kochi (Google) wrote:
> > > I don't think this is not that hard to measure/compare how much time
> > > spent with/without the new code for the benchmark.
> > 
> > With Patch https://codereview.chromium.org/2967493002/, no regression is
> > reported, which indicates calling NextFocusableElementInForm() from
> > TextInputFlags() is introducing the regression. Since I am running the tests
> on
> > trybot, I am not sure, how do I inspect my logs in it ?
> 
> Can you run the test with your local machine and Android devices locally?
> If so, you can tentatively have a call counter in TextInputFlags(), and
> spit out debug log whenever it's called, or preferably at exit.
> 
> From the perf bot results, I saw general tendency that desktops bots regress
> more
> than android bots, though I'm not completely sure.  That may indicate that
> the number of calls into TextInputFlags() during scrolling differ between
> Androids and desktops.
> 
> This feature is currently Android-only, so regression on non-Android desktops
is
> never accepted.

kochi@ - One observation is, even though visual impact of feature is only in
Android, but TextInputFlags() is getting called for all other platforms, so
ideally, regression has same impact on all platforms.

[Takayoshi Kochi (Google), 2017-07-14 09:10:03]

On 2017/07/14 08:32:23, AKVT wrote:
> On 2017/07/14 08:15:23, Takayoshi Kochi (Google) wrote:
> > On 2017/07/12 06:29:57, AKVT wrote:
> > > On 2017/07/11 06:24:37, Takayoshi Kochi (Google) wrote:
> > > > I don't think this is not that hard to measure/compare how much time
> > > > spent with/without the new code for the benchmark.
> > > 
> > > With Patch https://codereview.chromium.org/2967493002/, no regression is
> > > reported, which indicates calling NextFocusableElementInForm() from
> > > TextInputFlags() is introducing the regression. Since I am running the
tests
> > on
> > > trybot, I am not sure, how do I inspect my logs in it ?
> > 
> > Can you run the test with your local machine and Android devices locally?
> > If so, you can tentatively have a call counter in TextInputFlags(), and
> > spit out debug log whenever it's called, or preferably at exit.
> > 
> > From the perf bot results, I saw general tendency that desktops bots regress
> > more
> > than android bots, though I'm not completely sure.  That may indicate that
> > the number of calls into TextInputFlags() during scrolling differ between
> > Androids and desktops.
> > 
> > This feature is currently Android-only, so regression on non-Android
desktops
> is
> > never accepted.
> 
> kochi@ - One observation is, even though visual impact of feature is only in
> Android, but TextInputFlags() is getting called for all other platforms, so
> ideally, regression has same impact on all platforms.

My guess (to explain the difference of regression between Android and desktops)
is that Android does something different than desktop while scrolling is
active which results in less calls into TextInputFlags(), but I can be wrong.
I think you underestimate how many times TextInputInfo update IPC happens.

So at the worst case, you have to comment out the calls to
NextFocusableElementInForm()
by #if defined(OS_ANDROID).

[AKVT, 2017-07-14 09:13:09]

On 2017/07/14 09:10:03, Takayoshi Kochi (Google) wrote:
> On 2017/07/14 08:32:23, AKVT wrote:
> > On 2017/07/14 08:15:23, Takayoshi Kochi (Google) wrote:
> > > On 2017/07/12 06:29:57, AKVT wrote:
> > > > On 2017/07/11 06:24:37, Takayoshi Kochi (Google) wrote:
> > > > > I don't think this is not that hard to measure/compare how much time
> > > > > spent with/without the new code for the benchmark.
> > > > 
> > > > With Patch https://codereview.chromium.org/2967493002/, no regression is
> > > > reported, which indicates calling NextFocusableElementInForm() from
> > > > TextInputFlags() is introducing the regression. Since I am running the
> tests
> > > on
> > > > trybot, I am not sure, how do I inspect my logs in it ?
> > > 
> > > Can you run the test with your local machine and Android devices locally?
> > > If so, you can tentatively have a call counter in TextInputFlags(), and
> > > spit out debug log whenever it's called, or preferably at exit.
> > > 
> > > From the perf bot results, I saw general tendency that desktops bots
regress
> > > more
> > > than android bots, though I'm not completely sure.  That may indicate that
> > > the number of calls into TextInputFlags() during scrolling differ between
> > > Androids and desktops.
> > > 
> > > This feature is currently Android-only, so regression on non-Android
> desktops
> > is
> > > never accepted.
> > 
> > kochi@ - One observation is, even though visual impact of feature is only in
> > Android, but TextInputFlags() is getting called for all other platforms, so
> > ideally, regression has same impact on all platforms.
> 
> My guess (to explain the difference of regression between Android and
desktops)
> is that Android does something different than desktop while scrolling is
> active which results in less calls into TextInputFlags(), but I can be wrong.
> I think you underestimate how many times TextInputInfo update IPC happens.
> 
> So at the worst case, you have to comment out the calls to
> NextFocusableElementInForm()
> by #if defined(OS_ANDROID).

kochi@ - Thanks for that hint. I think that way we can suppress other platform
regression.
Meanwhile I will run the performance test in Android platform.

[AKVT, 2017-07-18 11:11:44]

On 2017/07/14 09:13:09, AKVT wrote:
> On 2017/07/14 09:10:03, Takayoshi Kochi (Google) wrote:
> > On 2017/07/14 08:32:23, AKVT wrote:
> > > On 2017/07/14 08:15:23, Takayoshi Kochi (Google) wrote:
> > > > On 2017/07/12 06:29:57, AKVT wrote:
> > > > > On 2017/07/11 06:24:37, Takayoshi Kochi (Google) wrote:
> > > > > > I don't think this is not that hard to measure/compare how much time
> > > > > > spent with/without the new code for the benchmark.
> > > > > 
> > > > > With Patch https://codereview.chromium.org/2967493002/, no regression
is
> > > > > reported, which indicates calling NextFocusableElementInForm() from
> > > > > TextInputFlags() is introducing the regression. Since I am running the
> > tests
> > > > on
> > > > > trybot, I am not sure, how do I inspect my logs in it ?
> > > > 
> > > > Can you run the test with your local machine and Android devices
locally?
> > > > If so, you can tentatively have a call counter in TextInputFlags(), and
> > > > spit out debug log whenever it's called, or preferably at exit.
> > > > 
> > > > From the perf bot results, I saw general tendency that desktops bots
> regress
> > > > more
> > > > than android bots, though I'm not completely sure.  That may indicate
that
> > > > the number of calls into TextInputFlags() during scrolling differ
between
> > > > Androids and desktops.
> > > > 
> > > > This feature is currently Android-only, so regression on non-Android
> > desktops
> > > is
> > > > never accepted.
> > > 
> > > kochi@ - One observation is, even though visual impact of feature is only
in
> > > Android, but TextInputFlags() is getting called for all other platforms,
so
> > > ideally, regression has same impact on all platforms.
> > 
> > My guess (to explain the difference of regression between Android and
> desktops)
> > is that Android does something different than desktop while scrolling is
> > active which results in less calls into TextInputFlags(), but I can be
wrong.
> > I think you underestimate how many times TextInputInfo update IPC happens.
> > 
> > So at the worst case, you have to comment out the calls to
> > NextFocusableElementInForm()
> > by #if defined(OS_ANDROID).
> 
> kochi@ - Thanks for that hint. I think that way we can suppress other platform
> regression.
> Meanwhile I will run the performance test in Android platform.

I got following errors while running telemetry tests in Android device. I tried
2 rooted device and an unrooted device of Google Pixel.

Locals:
  msg       : "Timed out waiting for 'device_online_with_root', wait of 1.0 secs
required but only 0.8 secs left"
  remaining : 0.7803859710693359
  required  : 1

[  PASSED  ] 0 tests.
[  FAILED  ] 1 test, listed below:
[  FAILED  ]  browse:social:facebook_infinite_scroll@{'case': 'browse', 'group':
'social'}

1 FAILED TEST

View result at
file:///home/ajithk/EXTRA_HDD/ANDROID_BROWSER/OPEN_SOURCE_CHROME_PATCHES/src/tools/perf/results.html
INFO:devil.utils.cmd_helper:[host]>
/home/ajithk/EXTRA_HDD/ANDROID_BROWSER/OPEN_SOURCE_CHROME_PATCHES/src/third_party/catapult/devil/bin/deps/linux2/x86_64/bin/adb
-s 98891935505a48334630 shell '( rm -f /data/local/chrome-trace-config.json
);echo %$?'
INFO:devil.utils.cmd_helper:[host]>
/home/ajithk/EXTRA_HDD/ANDROID_BROWSER/OPEN_SOURCE_CHROME_PATCHES/src/third_party/catapult/devil/bin/deps/linux2/x86_64/bin/adb
-s 98891935505a48334630 shell '( dumpsys battery );echo %$?'
WARNING:devil.android.battery_utils:Unknown line found in dumpsys battery:
"BatteryInfoBackUp"
INFO:root:Charging status checked at exit.

I will continue the discussion in gerrit review now onward.

[nasko, 2017-07-18 23:57:11]

There isn't much for me to review in content/, which only contains Java related
changes. Please use someone working on the android bits to review those parts.

[AKVT, 2017-08-29 02:37:43]

On 2017/07/18 23:57:11, nasko wrote:
> There isn't much for me to review in content/, which only contains Java
related
> changes. Please use someone working on the android bits to review those parts.

This is landed @
https://chromium-review.googlesource.com/c/chromium/src/+/574514. Hence closing
this review. Thank you!