Notify WebContentsObservers of user interactions.

Notify WebContentsObservers of user interactions.

This CL allows web contents observers to receive notifications of user
input when the contents is focused. User input is taken to be one of:

1. mouse down event
2. raw key down event
3. gesture tap event

The type of input is propagated to the observer, but all other details
are suppressed. This extends the existing
WebContentsObserver::OnUserGesture in two ways:

1. firing on all raw keypress events, instead of only enter and space;
2. providing the input type that triggered the call.

This CL refactors the site engagement service to use the new user
interaction notification in place of registering input callbacks on
RenderWidgetHost. It is intended that other consumers of
WebContentsObserver::OnUserGesture will be migrated to this new
method in a follow-up CL. Consumers of the RenderWidgetHost
mouse and keypress callback API may also be migrated to this
method.

BUG=548011, 464234
Committed: https://crrev.com/2dd142dd17f23127ac4a135363fe2580359150d6
Cr-Commit-Position: refs/heads/master@{#356772}

[jdduke (slow), 2015-10-21 20:53:51]

jdduke@chromium.org changed reviewers:
+ jdduke@chromium.org

[jdduke (slow), 2015-10-21 20:53:52]

Either this or the observer callback approach we discussed are fine, IMO.

https://codereview.chromium.org/1388293002/diff/1/content/browser/renderer_ho...
File content/browser/renderer_host/render_widget_host_impl.cc (right):

https://codereview.chromium.org/1388293002/diff/1/content/browser/renderer_ho...
content/browser/renderer_host/render_widget_host_impl.cc:1110: if
(key_event.type == WebKeyboardEvent::RawKeyDown)
Let's remove the explicit call here and in ForwardWheelEvent above, and instead
have a new conditional in FilterInputEvent that calls the method for the
relevant types.

https://codereview.chromium.org/1388293002/diff/1/content/public/browser/web_...
File content/public/browser/web_contents_observer.h (right):

https://codereview.chromium.org/1388293002/diff/1/content/public/browser/web_...
content/public/browser/web_contents_observer.h:316: // This indicates that the
next navigation was triggered by a user gesture.
Perhaps a TODO Here to remove this in favor of the below method.

https://codereview.chromium.org/1388293002/diff/1/content/public/browser/web_...
content/public/browser/web_contents_observer.h:322: virtual void
DidGetUserInput(const blink::WebInputEvent::Type type) {}
Let's call this |DidStartUserInteraction|, to make it more suggestive that this
is a subset of event types.

[dominickn, 2015-10-26 04:14:24]

Thanks!

https://codereview.chromium.org/1388293002/diff/1/content/browser/renderer_ho...
File content/browser/renderer_host/render_widget_host_impl.cc (right):

https://codereview.chromium.org/1388293002/diff/1/content/browser/renderer_ho...
content/browser/renderer_host/render_widget_host_impl.cc:1110: if
(key_event.type == WebKeyboardEvent::RawKeyDown)
On 2015/10/21 20:53:51, jdduke wrote:
> Let's remove the explicit call here and in ForwardWheelEvent above, and
instead
> have a new conditional in FilterInputEvent that calls the method for the
> relevant types.

Done.

https://codereview.chromium.org/1388293002/diff/1/content/public/browser/web_...
File content/public/browser/web_contents_observer.h (right):

https://codereview.chromium.org/1388293002/diff/1/content/public/browser/web_...
content/public/browser/web_contents_observer.h:316: // This indicates that the
next navigation was triggered by a user gesture.
On 2015/10/21 20:53:52, jdduke wrote:
> Perhaps a TODO Here to remove this in favor of the below method.

Done.

https://codereview.chromium.org/1388293002/diff/1/content/public/browser/web_...
content/public/browser/web_contents_observer.h:322: virtual void
DidGetUserInput(const blink::WebInputEvent::Type type) {}
On 2015/10/21 20:53:51, jdduke wrote:
> Let's call this |DidStartUserInteraction|, to make it more suggestive that
this
> is a subset of event types.

Done.

[jdduke (slow), 2015-10-26 16:02:53]

No bug?

I think this is fine, main nit here is to keep the naming consistent, i.e., make
sure the naming indicates the "start" of an interaction.

Also, I may have to hand this off, I've left the Chrome project and won't be an
OWNER after today. Adding tdresser@ who should be able to help.

https://codereview.chromium.org/1388293002/diff/20001/content/browser/rendere...
File content/browser/renderer_host/render_widget_host_impl.h (right):

https://codereview.chromium.org/1388293002/diff/20001/content/browser/rendere...
content/browser/renderer_host/render_widget_host_impl.h:524: virtual void
OnUserInteraction(const blink::WebInputEvent::Type type) {}
Should we keep the naming consistent, e.g., OnUserInteractionStarted or
something like that?

[nasko, 2015-10-26 17:18:43]

nasko@chromium.org changed reviewers:
+ nasko@chromium.org

[nasko, 2015-10-26 17:18:44]

A drive by review. Please include a BUG with details why this is needed. Also,
we have a rule in content/ that we don't add new APIs without any usage of it.
Please include any code that is going to consume this new API in the same CL.

https://codereview.chromium.org/1388293002/diff/20001/content/public/browser/...
File content/public/browser/web_contents_observer.h (right):

https://codereview.chromium.org/1388293002/diff/20001/content/public/browser/...
content/public/browser/web_contents_observer.h:324: virtual void
DidStartUserInteraction(const blink::WebInputEvent::Type type) {}
Any method that has a Start in its name should have a corresponding Stop method.
I don't see one. Why is that?

[dominickn, 2015-10-26 23:40:29]

Description was changed from

==========
Add user input notifications to web contents observers.

This CL allows web contents observers to receive notifications of user
input when the contents is focused. User input is taken to be one of:

1. mouse down event
2. mouse wheel event
3. raw key down event
4. gesture tap event

The type of input is propagated to the observer, but all other details
are suppressed.

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

to

==========
Add user interaction notifications to web contents observers.

This CL allows web contents observers to receive notifications of user
input when the contents is focused. User input is taken to be one of:

1. mouse down event
2. mouse wheel event
3. raw key down event
4. gesture tap event

The type of input is propagated to the observer, but all other details
are suppressed.

BUG=548011
==========

[dominickn, 2015-10-27 00:19:53]

Description was changed from

==========
Add user interaction notifications to web contents observers.

This CL allows web contents observers to receive notifications of user
input when the contents is focused. User input is taken to be one of:

1. mouse down event
2. mouse wheel event
3. raw key down event
4. gesture tap event

The type of input is propagated to the observer, but all other details
are suppressed.

BUG=548011
==========

to

==========
Add user interaction notifications to web contents observers.

This CL allows web contents observers to receive notifications of user
input when the contents is focused. User input is taken to be one of:

1. mouse down event
2. mouse wheel event
3. raw key down event
4. gesture tap event

The type of input is propagated to the observer, but all other details
are suppressed.

BUG=548011,464234
==========

[dominickn, 2015-10-27 06:19:17]

dominickn@chromium.org changed reviewers:
+ calamity@chromium.org

[dominickn, 2015-10-27 06:21:22]

Description was changed from

==========
Add user interaction notifications to web contents observers.

This CL allows web contents observers to receive notifications of user
input when the contents is focused. User input is taken to be one of:

1. mouse down event
2. mouse wheel event
3. raw key down event
4. gesture tap event

The type of input is propagated to the observer, but all other details
are suppressed.

BUG=548011,464234
==========

to

==========
Notify WebContentsObservers of user interactions.

This CL allows web contents observers to receive notifications of user
input when the contents is focused. User input is taken to be one of:

1. mouse down event
2. mouse wheel event
3. raw key down event
4. gesture tap event

The type of input is propagated to the observer, but all other details
are suppressed. It is intended that current consumers of
WebContentsObserver::OnUserGesture will be migrated to this new
method.

This CL also refactors the site engagement service to use the new
user input notification in place of registering input callbacks on
RenderWidgetHost.

BUG=548011,464234
==========

[dominickn, 2015-10-27 07:03:57]

@calamity: please review site engagement stuff.

@jdduke/@nasko: I've now filed a bug. There wasn't one before as this was a
proof of concept CL that evolved. :)

https://codereview.chromium.org/1388293002/diff/20001/content/browser/rendere...
File content/browser/renderer_host/render_widget_host_impl.h (right):

https://codereview.chromium.org/1388293002/diff/20001/content/browser/rendere...
content/browser/renderer_host/render_widget_host_impl.h:524: virtual void
OnUserInteraction(const blink::WebInputEvent::Type type) {}
On 2015/10/26 16:02:53, jdduke (slow) wrote:
> Should we keep the naming consistent, e.g., OnUserInteractionStarted or
> something like that?

From nasko's comment, I've removed the Start prefix and replaced it with Get in
the Observer and nothing elsewhere. This is consistent with OnUserGesture

https://codereview.chromium.org/1388293002/diff/20001/content/public/browser/...
File content/public/browser/web_contents_observer.h (right):

https://codereview.chromium.org/1388293002/diff/20001/content/public/browser/...
content/public/browser/web_contents_observer.h:324: virtual void
DidStartUserInteraction(const blink::WebInputEvent::Type type) {}
On 2015/10/26 17:18:44, nasko (slow to review) wrote:
> Any method that has a Start in its name should have a corresponding Stop
method.
> I don't see one. Why is that?

The naming was a reviewer suggestion. I've changed it to remove the Start and
the implication that there should be a stop.

[nasko, 2015-10-27 13:41:19]

My main overall concern is whether this will be a performance concern,
especially as mouse wheel events tend to be very bursty and can affect scrolling
behavior.

https://codereview.chromium.org/1388293002/diff/40001/content/browser/rendere...
File content/browser/renderer_host/render_view_host_delegate.h (right):

https://codereview.chromium.org/1388293002/diff/40001/content/browser/rendere...
content/browser/renderer_host/render_view_host_delegate.h:147: virtual void
OnUserInteraction(const blink::WebInputEvent::Type type) {}
The RenderViewHost object is deprecated and actively being disentangled from
RenderWidgetHost and hopefully will disappear not too far in the future. Please
move this over to the RenderWidgetHostDelegate, which is the equivalent of this
and still gets up to WebContents. It will also avoid the top through RVH, which
isn't necessary anyway.

https://codereview.chromium.org/1388293002/diff/40001/content/public/browser/...
File content/public/browser/web_contents_observer.h (right):

https://codereview.chromium.org/1388293002/diff/40001/content/public/browser/...
content/public/browser/web_contents_observer.h:318: // with the appropriate
filtering by input event type.
Is this TODO expected to be resolved in this CL?

https://codereview.chromium.org/1388293002/diff/40001/content/public/browser/...
content/public/browser/web_contents_observer.h:321: // Called when there has
been direct user interaction with the web contents.
nit: s/web contents/WebContents/

[dominickn, 2015-10-27 23:21:53]

Given your concern about mouse wheel events and scrolling performance, I've
removed them as triggers for OnUserInteraction. Thanks for the feedback!

https://codereview.chromium.org/1388293002/diff/40001/content/browser/rendere...
File content/browser/renderer_host/render_view_host_delegate.h (right):

https://codereview.chromium.org/1388293002/diff/40001/content/browser/rendere...
content/browser/renderer_host/render_view_host_delegate.h:147: virtual void
OnUserInteraction(const blink::WebInputEvent::Type type) {}
On 2015/10/27 13:41:19, nasko (slow to review) wrote:
> The RenderViewHost object is deprecated and actively being disentangled from
> RenderWidgetHost and hopefully will disappear not too far in the future.
Please
> move this over to the RenderWidgetHostDelegate, which is the equivalent of
this
> and still gets up to WebContents. It will also avoid the top through RVH,
which
> isn't necessary anyway.

Done.

https://codereview.chromium.org/1388293002/diff/40001/content/public/browser/...
File content/public/browser/web_contents_observer.h (right):

https://codereview.chromium.org/1388293002/diff/40001/content/public/browser/...
content/public/browser/web_contents_observer.h:318: // with the appropriate
filtering by input event type.
On 2015/10/27 13:41:19, nasko (slow to review) wrote:
> Is this TODO expected to be resolved in this CL?

No, I was planning on doing that in a separate CL. However, if you'd prefer it
all done in this CL then I'm happy to do it here. :)

https://codereview.chromium.org/1388293002/diff/40001/content/public/browser/...
content/public/browser/web_contents_observer.h:321: // Called when there has
been direct user interaction with the web contents.
On 2015/10/27 13:41:19, nasko (slow to review) wrote:
> nit: s/web contents/WebContents/

Done.

[dominickn, 2015-10-27 23:22:22]

Description was changed from

==========
Notify WebContentsObservers of user interactions.

This CL allows web contents observers to receive notifications of user
input when the contents is focused. User input is taken to be one of:

1. mouse down event
2. mouse wheel event
3. raw key down event
4. gesture tap event

The type of input is propagated to the observer, but all other details
are suppressed. It is intended that current consumers of
WebContentsObserver::OnUserGesture will be migrated to this new
method.

This CL also refactors the site engagement service to use the new
user input notification in place of registering input callbacks on
RenderWidgetHost.

BUG=548011,464234
==========

to

==========
Notify WebContentsObservers of user interactions.

This CL allows web contents observers to receive notifications of user
input when the contents is focused. User input is taken to be one of:

1. mouse down event
2. raw key down event
3. gesture tap event

The type of input is propagated to the observer, but all other details
are suppressed. It is intended that current consumers of
WebContentsObserver::OnUserGesture will be migrated to this new
method.

This CL also refactors the site engagement service to use the new
user input notification in place of registering input callbacks on
RenderWidgetHost.

BUG=548011,464234
==========

[calamity, 2015-10-28 03:00:25]

lgtm.

It's unfortunate that we lose mouse scrolls as an engagement event. Perhaps we
can explore rate-limiting the scroll event in RenderWidgetHostImpl if
performance is a concern.

https://codereview.chromium.org/1388293002/diff/60001/chrome/browser/engageme...
File chrome/browser/engagement/site_engagement_helper.cc (right):

https://codereview.chromium.org/1388293002/diff/60001/chrome/browser/engageme...
chrome/browser/engagement/site_engagement_helper.cc:72: if (is_tracking_) {
nit: Invert and early return.

https://codereview.chromium.org/1388293002/diff/60001/chrome/browser/engageme...
chrome/browser/engagement/site_engagement_helper.cc:77: } else if (type ==
blink::WebInputEvent::GestureTapDown) {
Consider a switch-case here.

https://codereview.chromium.org/1388293002/diff/60001/chrome/browser/engageme...
File chrome/browser/engagement/site_engagement_helper_unittest.cc (right):

https://codereview.chromium.org/1388293002/diff/60001/chrome/browser/engageme...
chrome/browser/engagement/site_engagement_helper_unittest.cc:102: // Simulate
key presses for a different link.
nit: s/key presses/user input/ and above.

https://codereview.chromium.org/1388293002/diff/60001/chrome/browser/engageme...
chrome/browser/engagement/site_engagement_helper_unittest.cc:357:
EXPECT_TRUE(IsTracking(helper.get()));
Given that the majority of this test was testing actual tab show/hide
interaction which we don't have, this can be stripped down a lot. Most of the
navigations can be removed (esp background tab creation), all of the
ActivateTabAts can be removed.

[dominickn, 2015-10-28 03:28:17]

Thanks! Also added histograms.xml which I forgot in the earlier upload.

https://codereview.chromium.org/1388293002/diff/60001/chrome/browser/engageme...
File chrome/browser/engagement/site_engagement_helper.cc (right):

https://codereview.chromium.org/1388293002/diff/60001/chrome/browser/engageme...
chrome/browser/engagement/site_engagement_helper.cc:72: if (is_tracking_) {
On 2015/10/28 03:00:24, calamity wrote:
> nit: Invert and early return.

Done.

https://codereview.chromium.org/1388293002/diff/60001/chrome/browser/engageme...
chrome/browser/engagement/site_engagement_helper.cc:77: } else if (type ==
blink::WebInputEvent::GestureTapDown) {
On 2015/10/28 03:00:24, calamity wrote:
> Consider a switch-case here.

Done.

https://codereview.chromium.org/1388293002/diff/60001/chrome/browser/engageme...
File chrome/browser/engagement/site_engagement_helper_unittest.cc (right):

https://codereview.chromium.org/1388293002/diff/60001/chrome/browser/engageme...
chrome/browser/engagement/site_engagement_helper_unittest.cc:102: // Simulate
key presses for a different link.
On 2015/10/28 03:00:25, calamity wrote:
> nit: s/key presses/user input/ and above.

Done.

https://codereview.chromium.org/1388293002/diff/60001/chrome/browser/engageme...
chrome/browser/engagement/site_engagement_helper_unittest.cc:357:
EXPECT_TRUE(IsTracking(helper.get()));
On 2015/10/28 03:00:25, calamity wrote:
> Given that the majority of this test was testing actual tab show/hide
> interaction which we don't have, this can be stripped down a lot. Most of the
> navigations can be removed (esp background tab creation), all of the
> ActivateTabAts can be removed.

Done.

[nasko, 2015-10-28 17:36:12]

https://codereview.chromium.org/1388293002/diff/40001/content/public/browser/...
File content/public/browser/web_contents_observer.h (right):

https://codereview.chromium.org/1388293002/diff/40001/content/public/browser/...
content/public/browser/web_contents_observer.h:318: // with the appropriate
filtering by input event type.
On 2015/10/27 23:21:53, dominickn wrote:
> On 2015/10/27 13:41:19, nasko (slow to review) wrote:
> > Is this TODO expected to be resolved in this CL?
> 
> No, I was planning on doing that in a separate CL. However, if you'd prefer it
> all done in this CL then I'm happy to do it here. :)

I don't have very strong preference which way it happens. I do have a strong
desire that this happens very quickly after this one lands.

https://codereview.chromium.org/1388293002/diff/80001/content/browser/rendere...
File content/browser/renderer_host/render_widget_host_impl.cc (right):

https://codereview.chromium.org/1388293002/diff/80001/content/browser/rendere...
content/browser/renderer_host/render_widget_host_impl.cc:1451:
delegate_->OnUserInteraction(type);
Why have a separate method for a two line body? Can't this just be inlined into
the callsite?

https://codereview.chromium.org/1388293002/diff/80001/content/browser/rendere...
File content/browser/renderer_host/render_widget_host_impl.h (right):

https://codereview.chromium.org/1388293002/diff/80001/content/browser/rendere...
content/browser/renderer_host/render_widget_host_impl.h:583: // event; and 3)
any gesture tap event (which includes taps and scrolls).
If this is again doing extra work during scrolling, perf should be considered. I
would suggest discussing this with nduca@ or someone else more versed in perf
than myself.

[dominickn, 2015-10-29 00:03:19]

> I don't have very strong preference which way it happens. I do have a strong
> desire that this happens very quickly after this one lands.

Acknowledged. I'm putting together the CL now, and I'm keeping it separate as
it's turning out to be quite big (mainly renaming that touches a lot of files).

https://codereview.chromium.org/1388293002/diff/80001/content/browser/rendere...
File content/browser/renderer_host/render_widget_host_impl.cc (right):

https://codereview.chromium.org/1388293002/diff/80001/content/browser/rendere...
content/browser/renderer_host/render_widget_host_impl.cc:1451:
delegate_->OnUserInteraction(type);
On 2015/10/28 17:36:12, nasko (slow to review) wrote:
> Why have a separate method for a two line body? Can't this just be inlined
into
> the callsite?

Done.

https://codereview.chromium.org/1388293002/diff/80001/content/browser/rendere...
File content/browser/renderer_host/render_widget_host_impl.h (right):

https://codereview.chromium.org/1388293002/diff/80001/content/browser/rendere...
content/browser/renderer_host/render_widget_host_impl.h:583: // event; and 3)
any gesture tap event (which includes taps and scrolls).
On 2015/10/28 17:36:12, nasko (slow to review) wrote:
> If this is again doing extra work during scrolling, perf should be considered.
I
> would suggest discussing this with nduca@ or someone else more versed in perf
> than myself.

GestureTapDown fires once at the beginning of a scroll, but no more times after
that while the user is scrolling until they tap again on the screen. This is in
contrast to MouseWheel, which continually fires while scrolling. There's no
additional load during scrolling.

[nasko, 2015-10-29 00:07:26]

LGTM

https://codereview.chromium.org/1388293002/diff/80001/content/browser/rendere...
File content/browser/renderer_host/render_widget_host_impl.h (right):

https://codereview.chromium.org/1388293002/diff/80001/content/browser/rendere...
content/browser/renderer_host/render_widget_host_impl.h:583: // event; and 3)
any gesture tap event (which includes taps and scrolls).
On 2015/10/29 00:03:19, dominickn wrote:
> On 2015/10/28 17:36:12, nasko (slow to review) wrote:
> > If this is again doing extra work during scrolling, perf should be
considered.
> I
> > would suggest discussing this with nduca@ or someone else more versed in
perf
> > than myself.
> 
> GestureTapDown fires once at the beginning of a scroll, but no more times
after
> that while the user is scrolling until they tap again on the screen. This is
in
> contrast to MouseWheel, which continually fires while scrolling. There's no
> additional load during scrolling. 

Awesome! Thanks for the context.

[dominickn, 2015-10-29 00:29:46]

Patchset #6 (id:100001) has been deleted

[dominickn, 2015-10-29 00:31:43]

dominickn@chromium.org changed reviewers:
+ isherman@chromium.org

[dominickn, 2015-10-29 00:32:27]

Thanks! 

+isherman: please review histograms.xml.

[dominickn, 2015-10-29 00:36:09]

Description was changed from

==========
Notify WebContentsObservers of user interactions.

This CL allows web contents observers to receive notifications of user
input when the contents is focused. User input is taken to be one of:

1. mouse down event
2. raw key down event
3. gesture tap event

The type of input is propagated to the observer, but all other details
are suppressed. It is intended that current consumers of
WebContentsObserver::OnUserGesture will be migrated to this new
method.

This CL also refactors the site engagement service to use the new
user input notification in place of registering input callbacks on
RenderWidgetHost.

BUG=548011,464234
==========

to

==========
Notify WebContentsObservers of user interactions.

This CL allows web contents observers to receive notifications of user
input when the contents is focused. User input is taken to be one of:

1. mouse down event
2. raw key down event
3. gesture tap event

The type of input is propagated to the observer, but all other details
are suppressed. This extends the existing
WebContentsObserver::OnUserGesture in two ways:

1. firing on all raw keypress events, instead of only enter and space;
2. providing the input type that triggered the call.

This CL refactors the site engagement service to use the new user
interaction notification in place of registering input callbacks on
RenderWidgetHost. It is intended that other consumers of
WebContentsObserver::OnUserGesture will be migrated to this new
method in a follow-up CL. Consumers of the RenderWidgetHost
mouse and keypress callback API may also be migrated to this
method.

BUG=548011,464234
==========

[Ilya Sherman, 2015-10-29 00:38:52]

histograms.xml lgtm % nit:

https://codereview.chromium.org/1388293002/diff/120001/tools/metrics/histogra...
File tools/metrics/histograms/histograms.xml (right):

https://codereview.chromium.org/1388293002/diff/120001/tools/metrics/histogra...
tools/metrics/histograms/histograms.xml:72105: +  <int value="3"
label="Gesture"/>
Optional nit: Perhaps "Tap gesture"?  Just "Gesture" is somewhat vague.

[jdduke (slow), 2015-10-29 00:50:17]

https://codereview.chromium.org/1388293002/diff/120001/tools/metrics/histogra...
File tools/metrics/histograms/histograms.xml (right):

https://codereview.chromium.org/1388293002/diff/120001/tools/metrics/histogra...
tools/metrics/histograms/histograms.xml:72105: +  <int value="3"
label="Gesture"/>
On 2015/10/29 00:38:52, Ilya Sherman wrote:
> Optional nit: Perhaps "Tap gesture"?  Just "Gesture" is somewhat vague.

Perhaps "Touch gesture", TapDown fires at the start of any kind of touch gesture
(scroll/tap/pinch).

[dominickn, 2015-10-29 01:48:02]

Thanks everyone. :)

https://codereview.chromium.org/1388293002/diff/120001/tools/metrics/histogra...
File tools/metrics/histograms/histograms.xml (right):

https://codereview.chromium.org/1388293002/diff/120001/tools/metrics/histogra...
tools/metrics/histograms/histograms.xml:72105: +  <int value="3"
label="Gesture"/>
On 2015/10/29 00:50:17, jdduke (slow) wrote:
> On 2015/10/29 00:38:52, Ilya Sherman wrote:
> > Optional nit: Perhaps "Tap gesture"?  Just "Gesture" is somewhat vague.
> 
> Perhaps "Touch gesture", TapDown fires at the start of any kind of touch
gesture
> (scroll/tap/pinch).

Done.

[dominickn, 2015-10-29 03:21:16]

The CQ bit was checked by dominickn@chromium.org

[dominickn, 2015-10-29 03:21:16]

The patchset sent to the CQ was uploaded after l-g-t-m from
calamity@chromium.org, nasko@chromium.org, isherman@chromium.org
Link to the patchset: https://codereview.chromium.org/1388293002/#ps140001
(title: "Addressing nits")

[commit-bot: I haz the power, 2015-10-29 03:22:01]

CQ is trying da patch. Follow status at
 https://chromium-cq-status.appspot.com/patch-status/1388293002/140001
View timeline at
 https://chromium-cq-status.appspot.com/patch-timeline/1388293002/140001

[commit-bot: I haz the power, 2015-10-29 05:31:00]

Committed patchset #7 (id:140001)

[commit-bot: I haz the power, 2015-10-29 05:31:54]

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