Sending generated vote on password generation.

Sending generated vote on password generation.

The generating of password by user is strong indication that the current form is suitable for generation and we can use it for improving our heuristics.

This patch adds |generation_event| to uploaded field vote (in AutofillField structure and in AutofillUploadContents proto) with information about generation event which happened.

BUG=552420
Committed: https://crrev.com/c0a523a2e2d85e487c3aa32ad57ac1a3e4694d46
Cr-Commit-Position: refs/heads/master@{#376968}

[dvadym, 2016-02-17 12:31:06]

Description was changed from

==========
Sending generated vote on password generation

It is not ready for code review yet

BUG=552420
==========

to

==========
Sending generated vote on password generation.

When the user generates password on some form, that's very strong confirmation
that this form is suitable for generation and we can use it for improving our
heuristics.

This patch adds one new field to uploaded field vote with information about
generation event which happened.

BUG=552420
==========

[dvadym, 2016-02-17 12:32:59]

Description was changed from

==========
Sending generated vote on password generation.

When the user generates password on some form, that's very strong confirmation
that this form is suitable for generation and we can use it for improving our
heuristics.

This patch adds one new field to uploaded field vote with information about
generation event which happened.

BUG=552420
==========

to

==========
Sending generated vote on password generation.

The generating of password by user on some form is strong confirmation that this
form is suitable for generation and we can use it for improving our heuristics.

This patch adds one new field to uploaded field vote with information about
generation event which happened.

BUG=552420
==========

[dvadym, 2016-02-17 12:38:20]

Description was changed from

==========
Sending generated vote on password generation.

The generating of password by user on some form is strong confirmation that this
form is suitable for generation and we can use it for improving our heuristics.

This patch adds one new field to uploaded field vote with information about
generation event which happened.

BUG=552420
==========

to

==========
Sending generated vote on password generation.

The generating of password by user is strong indication that the current form is
suitable for generation and we can use it for improving our heuristics.

This patch adds one new field to uploaded field vote with information about
generation event which happened.

BUG=552420
==========

[dvadym, 2016-02-17 12:40:16]

Description was changed from

==========
Sending generated vote on password generation.

The generating of password by user is strong indication that the current form is
suitable for generation and we can use it for improving our heuristics.

This patch adds one new field to uploaded field vote with information about
generation event which happened.

BUG=552420
==========

to

==========
Sending generated vote on password generation.

The generating of password by user is strong indication that the current form is
suitable for generation and we can use it for improving our heuristics.

This patch adds |generation_event| to uploaded field vote (in AutofillField
structure and in AutofillUploadContents proto) with information about generation
event which happened.

BUG=552420
==========

[dvadym, 2016-02-17 12:40:41]

dvadym@chromium.org changed reviewers:
+ vabr@chromium.org

[dvadym, 2016-02-17 12:40:42]

Hi Vaclav,

 Could you please review this CL?

Regards
Vadym

[dvadym, 2016-02-17 12:47:21]

https://codereview.chromium.org/1686063004/diff/160001/components/password_ma...
File components/password_manager/core/browser/password_form_manager.h (right):

https://codereview.chromium.org/1686063004/diff/160001/components/password_ma...
components/password_manager/core/browser/password_form_manager.h:503: // a
password that is not part of any password form stored for this origin
vabr@: this is addressing of your comment from
https://codereview.chromium.org/1476523004/#msg14, I hope you don't mind to add
such small fix here not in separate patch.

[vabr (Chromium), 2016-02-17 13:43:21]

vabr@chromium.org changed reviewers:
+ mathp@chromium.org

[vabr (Chromium), 2016-02-17 13:43:23]

LGTM with comments.

I did not review the IPC message header change, because you need the security
team for that.

Also, I'm adding mathp to check
components/autofill/core/browser/proto/server.proto.

Thanks!
Vaclav

https://codereview.chromium.org/1686063004/diff/160001/chrome/browser/passwor...
File chrome/browser/password_manager/chrome_password_manager_client.h (right):

https://codereview.chromium.org/1686063004/diff/160001/chrome/browser/passwor...
chrome/browser/password_manager/chrome_password_manager_client.h:130: // will be
no longer than |max_length|.
nit: Please explain the added arguments in the comment.

https://codereview.chromium.org/1686063004/diff/160001/components/autofill/co...
File components/autofill/content/renderer/password_generation_agent.cc (right):

https://codereview.chromium.org/1686063004/diff/160001/components/autofill/co...
components/autofill/content/renderer/password_generation_agent.cc:491:
is_manually_triggered = true;
nit: Currently this method is only called when the user triggers generation, so
setting the flag here is OK. But the contract for this method (in the comment
above its declaration) does not require that it is always called after the user
manually triggered generation. So in the future, someone could reuse it for the
automatic generation, resulting in bad votes. Could you please add the manual
triggering to the method's contract (preferably also to the browser-code side of
generation triggering)?

https://codereview.chromium.org/1686063004/diff/160001/components/autofill/co...
File components/autofill/content/renderer/password_generation_agent.h (right):

https://codereview.chromium.org/1686063004/diff/160001/components/autofill/co...
components/autofill/content/renderer/password_generation_agent.h:133: bool
is_manually_triggered;
nit: Missing an underscore at the end of the data member name.

https://codereview.chromium.org/1686063004/diff/160001/components/autofill/co...
File components/autofill/core/browser/autofill_field.h (right):

https://codereview.chromium.org/1686063004/diff/160001/components/autofill/co...
components/autofill/core/browser/autofill_field.h:85: PasswordGenerationEvent
generation_event() const { return generation_event_; }
nit: All the other getter-setter pairs have the order first setter then getter.
Please swap these to match that.

https://codereview.chromium.org/1686063004/diff/160001/components/autofill/co...
File components/autofill/core/browser/field_types.h (right):

https://codereview.chromium.org/1686063004/diff/160001/components/autofill/co...
components/autofill/core/browser/field_types.h:253: enum PasswordGenerationEvent
{
This name collides with the enum in
components/autofill/core/common/password_generation_util.h. Please rename the
new one.

https://codereview.chromium.org/1686063004/diff/160001/components/autofill/co...
File components/autofill/core/browser/proto/server.proto (right):

https://codereview.chromium.org/1686063004/diff/160001/components/autofill/co...
components/autofill/core/browser/proto/server.proto:77: optional fixed32
generation_event = 17;
I'd like mathp@ to check if this looks like a good place to add the information.

https://codereview.chromium.org/1686063004/diff/160001/components/autofill/co...
components/autofill/core/browser/proto/server.proto:92: }
nit: Do you know what is the change on this line? Is it adding/losing a newline?
Should we keep the current state?

https://codereview.chromium.org/1686063004/diff/160001/components/password_ma...
File components/password_manager/core/browser/password_form_manager.cc (right):

https://codereview.chromium.org/1686063004/diff/160001/components/password_ma...
components/password_manager/core/browser/password_form_manager.cc:832:
field->set_possible_types(std::move(types));
The argument of set_possible_types is a const ref, so moving |types| does not
buy us anything. Recent discussions on chromium-dev [1] indicate that we will
not be moving towards moving arguments by default. Also, the std::move has the
danger that somebody might miss it and use |types| below later.

So I vote for reverting this line to not using std::move.

[1]
https://groups.google.com/a/chromium.org/d/msg/chromium-dev/ZoAfW7GXUVI/fCYjk...

https://codereview.chromium.org/1686063004/diff/160001/components/password_ma...
components/password_manager/core/browser/password_form_manager.cc:916:
field->set_possible_types(std::move(types));
Ditto.

https://codereview.chromium.org/1686063004/diff/160001/components/password_ma...
components/password_manager/core/browser/password_form_manager.cc:935:
FormStructure form_structure(form_data);
nit: Why not inline form_data? It is short enough and not used below.

https://codereview.chromium.org/1686063004/diff/160001/components/password_ma...
components/password_manager/core/browser/password_form_manager.cc:967:
field->set_possible_types(std::move(types));
Remove std::move (see one of my comments above).

https://codereview.chromium.org/1686063004/diff/160001/components/password_ma...
File components/password_manager/core/browser/password_form_manager.h (right):

https://codereview.chromium.org/1686063004/diff/160001/components/password_ma...
components/password_manager/core/browser/password_form_manager.h:189:
base::string16 generation_element() { return generation_element_; }
const base::string16&

https://codereview.chromium.org/1686063004/diff/160001/components/password_ma...
components/password_manager/core/browser/password_form_manager.h:491: // Whether
password generation were manually triggered.
were -> was

https://codereview.chromium.org/1686063004/diff/160001/components/password_ma...
components/password_manager/core/browser/password_form_manager.h:503: // a
password that is not part of any password form stored for this origin
On 2016/02/17 12:47:21, dvadym wrote:
> vabr@: this is addressing of your comment from
> https://codereview.chromium.org/1476523004/#msg14, I hope you don't mind to
add
> such small fix here not in separate patch.

Acknowledged, thanks!

https://codereview.chromium.org/1686063004/diff/160001/components/password_ma...
File components/password_manager/core/browser/password_form_manager_unittest.cc
(right):

https://codereview.chromium.org/1686063004/diff/160001/components/password_ma...
components/password_manager/core/browser/password_form_manager_unittest.cc:531:
bool is_change_password_form) {
Please use SCOPED_TRACE() to record the two arguments. Otherwise it will be hard
to find out, which of the 4 variants failed, if one fails.

https://codereview.chromium.org/1686063004/diff/160001/components/password_ma...
components/password_manager/core/browser/password_form_manager_unittest.cc:587:
AUTOMATICALLY_TRIGGERED_GENERATION_ON_CHANGE_PASSWORD_FORM
Did you run git cl format?

[Mathieu, 2016-02-17 15:57:26]

https://codereview.chromium.org/1686063004/diff/160001/components/autofill/co...
File components/autofill/core/browser/proto/server.proto (right):

https://codereview.chromium.org/1686063004/diff/160001/components/autofill/co...
components/autofill/core/browser/proto/server.proto:77: optional fixed32
generation_event = 17;
On 2016/02/17 13:43:22, vabr (Chromium) wrote:
> I'd like mathp@ to check if this looks like a good place to add the
information.

I would prefer the enum PasswordGenerationEvent to be defined in this file.

here's how to define an enum in proto:
https://code.google.com/p/chromium/codesearch#chromium/src/sync/protocol/sync...

(the reason we don't have other enums in this file is that the protos are old.
New definitions should be more modern).

[dvadym, 2016-02-19 16:25:06]

Thanks Vaclav and Mathieu for comments. I've addressed all of them.

Mathieu@: is it correct way to use proto enums as in FormStructure.cc?

https://codereview.chromium.org/1686063004/diff/160001/chrome/browser/passwor...
File chrome/browser/password_manager/chrome_password_manager_client.h (right):

https://codereview.chromium.org/1686063004/diff/160001/chrome/browser/passwor...
chrome/browser/password_manager/chrome_password_manager_client.h:130: // will be
no longer than |max_length|.
On 2016/02/17 13:43:22, vabr (Chromium) wrote:
> nit: Please explain the added arguments in the comment.

I've added
// |generation_element| should contain a name of a password field at which
generation popup is attached.
  // |is_manually_triggered| informs whether it is automatically or manually
triggered generation.

https://codereview.chromium.org/1686063004/diff/160001/components/autofill/co...
File components/autofill/content/renderer/password_generation_agent.cc (right):

https://codereview.chromium.org/1686063004/diff/160001/components/autofill/co...
components/autofill/content/renderer/password_generation_agent.cc:491:
is_manually_triggered = true;
On 2016/02/17 13:43:22, vabr (Chromium) wrote:
> nit: Currently this method is only called when the user triggers generation,
so
> setting the flag here is OK. But the contract for this method (in the comment
> above its declaration) does not require that it is always called after the
user
> manually triggered generation. So in the future, someone could reuse it for
the
> automatic generation, resulting in bad votes. Could you please add the manual
> triggering to the method's contract (preferably also to the browser-code side
of
> generation triggering)?

Thanks, it makes perfect sense, I've renamed to UserTriggeredGeneratePassword

https://codereview.chromium.org/1686063004/diff/160001/components/autofill/co...
File components/autofill/content/renderer/password_generation_agent.h (right):

https://codereview.chromium.org/1686063004/diff/160001/components/autofill/co...
components/autofill/content/renderer/password_generation_agent.h:133: bool
is_manually_triggered;
On 2016/02/17 13:43:22, vabr (Chromium) wrote:
> nit: Missing an underscore at the end of the data member name.

Done.

https://codereview.chromium.org/1686063004/diff/160001/components/autofill/co...
File components/autofill/core/browser/autofill_field.h (right):

https://codereview.chromium.org/1686063004/diff/160001/components/autofill/co...
components/autofill/core/browser/autofill_field.h:85: PasswordGenerationEvent
generation_event() const { return generation_event_; }
On 2016/02/17 13:43:22, vabr (Chromium) wrote:
> nit: All the other getter-setter pairs have the order first setter then
getter.
> Please swap these to match that.

Done.

https://codereview.chromium.org/1686063004/diff/160001/components/autofill/co...
File components/autofill/core/browser/field_types.h (right):

https://codereview.chromium.org/1686063004/diff/160001/components/autofill/co...
components/autofill/core/browser/field_types.h:253: enum PasswordGenerationEvent
{
On 2016/02/17 13:43:22, vabr (Chromium) wrote:
> This name collides with the enum in
> components/autofill/core/common/password_generation_util.h. Please rename the
> new one.

Thanks, I've renamed to  PasswordGenerationType

https://codereview.chromium.org/1686063004/diff/160001/components/autofill/co...
File components/autofill/core/browser/proto/server.proto (right):

https://codereview.chromium.org/1686063004/diff/160001/components/autofill/co...
components/autofill/core/browser/proto/server.proto:77: optional fixed32
generation_event = 17;
On 2016/02/17 15:57:26, Mathieu Perreault wrote:
> On 2016/02/17 13:43:22, vabr (Chromium) wrote:
> > I'd like mathp@ to check if this looks like a good place to add the
> information.
> 
> I would prefer the enum PasswordGenerationEvent to be defined in this file.
> 
> here's how to define an enum in proto:
>
https://code.google.com/p/chromium/codesearch#chromium/src/sync/protocol/sync...
> 
> (the reason we don't have other enums in this file is that the protos are old.
> New definitions should be more modern).

Thanks, I've introduced an enum.

https://codereview.chromium.org/1686063004/diff/160001/components/autofill/co...
components/autofill/core/browser/proto/server.proto:92: }
On 2016/02/17 13:43:22, vabr (Chromium) wrote:
> nit: Do you know what is the change on this line? Is it adding/losing a
newline?
> Should we keep the current state?

I didn't do any changes and I don't see any reason why it shows that lines are
different. I even made git checkout master <this file>. So it seems like some
bug in a comparison tool.

https://codereview.chromium.org/1686063004/diff/160001/components/password_ma...
File components/password_manager/core/browser/password_form_manager.cc (right):

https://codereview.chromium.org/1686063004/diff/160001/components/password_ma...
components/password_manager/core/browser/password_form_manager.cc:832:
field->set_possible_types(std::move(types));
On 2016/02/17 13:43:22, vabr (Chromium) wrote:
> The argument of set_possible_types is a const ref, so moving |types| does not
> buy us anything. Recent discussions on chromium-dev [1] indicate that we will
> not be moving towards moving arguments by default. Also, the std::move has the
> danger that somebody might miss it and use |types| below later.
> 
> So I vote for reverting this line to not using std::move.
> 
> [1]
>
https://groups.google.com/a/chromium.org/d/msg/chromium-dev/ZoAfW7GXUVI/fCYjk...

Thanks for information about this discussions.

https://codereview.chromium.org/1686063004/diff/160001/components/password_ma...
components/password_manager/core/browser/password_form_manager.cc:916:
field->set_possible_types(std::move(types));
On 2016/02/17 13:43:22, vabr (Chromium) wrote:
> Ditto.

Done.

https://codereview.chromium.org/1686063004/diff/160001/components/password_ma...
components/password_manager/core/browser/password_form_manager.cc:935:
FormStructure form_structure(form_data);
On 2016/02/17 13:43:22, vabr (Chromium) wrote:
> nit: Why not inline form_data? It is short enough and not used below.

Done.

https://codereview.chromium.org/1686063004/diff/160001/components/password_ma...
components/password_manager/core/browser/password_form_manager.cc:967:
field->set_possible_types(std::move(types));
On 2016/02/17 13:43:22, vabr (Chromium) wrote:
> Remove std::move (see one of my comments above).

Done.

https://codereview.chromium.org/1686063004/diff/160001/components/password_ma...
File components/password_manager/core/browser/password_form_manager.h (right):

https://codereview.chromium.org/1686063004/diff/160001/components/password_ma...
components/password_manager/core/browser/password_form_manager.h:189:
base::string16 generation_element() { return generation_element_; }
On 2016/02/17 13:43:23, vabr (Chromium) wrote:
> const base::string16&

Done, thanks

https://codereview.chromium.org/1686063004/diff/160001/components/password_ma...
components/password_manager/core/browser/password_form_manager.h:491: // Whether
password generation were manually triggered.
On 2016/02/17 13:43:23, vabr (Chromium) wrote:
> were -> was

Done.

https://codereview.chromium.org/1686063004/diff/160001/components/password_ma...
File components/password_manager/core/browser/password_form_manager_unittest.cc
(right):

https://codereview.chromium.org/1686063004/diff/160001/components/password_ma...
components/password_manager/core/browser/password_form_manager_unittest.cc:531:
bool is_change_password_form) {
On 2016/02/17 13:43:23, vabr (Chromium) wrote:
> Please use SCOPED_TRACE() to record the two arguments. Otherwise it will be
hard
> to find out, which of the 4 variants failed, if one fails.

Done.

https://codereview.chromium.org/1686063004/diff/160001/components/password_ma...
components/password_manager/core/browser/password_form_manager_unittest.cc:587:
AUTOMATICALLY_TRIGGERED_GENERATION_ON_CHANGE_PASSWORD_FORM
On 2016/02/17 13:43:23, vabr (Chromium) wrote:
> Did you run git cl format?

Sure, but it looks like git cl format doesn't like such long names :). I've
formatted manually.

https://codereview.chromium.org/1686063004/diff/180001/components/autofill/co...
File components/autofill/core/browser/form_structure.cc (right):

https://codereview.chromium.org/1686063004/diff/180001/components/autofill/co...
components/autofill/core/browser/form_structure.cc:1114:
field->generation_type()));
Mathieu@: is it correct way to use proto enums?

[vabr (Chromium), 2016-02-22 11:59:31]

LGTM, thanks!
Vaclav

[Mathieu, 2016-02-22 13:25:20]

Sorry about the delay vadym! some details on the proto enum

https://codereview.chromium.org/1686063004/diff/180001/components/autofill/co...
File components/autofill/core/browser/autofill_field.h (right):

https://codereview.chromium.org/1686063004/diff/180001/components/autofill/co...
components/autofill/core/browser/autofill_field.h:157: PasswordGenerationType
generation_type_;
This should be of type AutofillUploadContents::Field::PasswordGenerationType.

https://codereview.chromium.org/1686063004/diff/180001/components/autofill/co...
File components/autofill/core/browser/field_types.h (right):

https://codereview.chromium.org/1686063004/diff/180001/components/autofill/co...
components/autofill/core/browser/field_types.h:253: enum PasswordGenerationType
{
The idea is that you remove this and only use the enum defined in the .proto
file. Right now they are redundant.

https://codereview.chromium.org/1686063004/diff/180001/components/autofill/co...
File components/autofill/core/browser/form_structure.cc (right):

https://codereview.chromium.org/1686063004/diff/180001/components/autofill/co...
components/autofill/core/browser/form_structure.cc:1114:
field->generation_type()));
On 2016/02/19 16:25:06, dvadym wrote:
> Mathieu@: is it correct way to use proto enums?

if |generation_type| is of type
AutofillUploadContents::Field::PasswordGenerationType, you wouldn't need the
cast here (probably also wouldn't need the ::autofill:: since you are already in
the autofill namespace?)

[dvadym, 2016-02-22 14:52:32]

Thanks Mathieu for comments. Yeah, it makes sense to use only one enum, namely
one from protobuf. I've removed the enum that I've introduced earlier on this
CL.

https://codereview.chromium.org/1686063004/diff/180001/components/autofill/co...
File components/autofill/core/browser/autofill_field.h (right):

https://codereview.chromium.org/1686063004/diff/180001/components/autofill/co...
components/autofill/core/browser/autofill_field.h:157: PasswordGenerationType
generation_type_;
On 2016/02/22 13:25:20, Mathieu Perreault wrote:
> This should be of type AutofillUploadContents::Field::PasswordGenerationType.

Done.

https://codereview.chromium.org/1686063004/diff/180001/components/autofill/co...
File components/autofill/core/browser/field_types.h (right):

https://codereview.chromium.org/1686063004/diff/180001/components/autofill/co...
components/autofill/core/browser/field_types.h:253: enum PasswordGenerationType
{
On 2016/02/22 13:25:20, Mathieu Perreault wrote:
> The idea is that you remove this and only use the enum defined in the .proto
> file. Right now they are redundant.

Done.

https://codereview.chromium.org/1686063004/diff/180001/components/autofill/co...
File components/autofill/core/browser/form_structure.cc (right):

https://codereview.chromium.org/1686063004/diff/180001/components/autofill/co...
components/autofill/core/browser/form_structure.cc:1114:
field->generation_type()));
On 2016/02/22 13:25:20, Mathieu Perreault wrote:
> On 2016/02/19 16:25:06, dvadym wrote:
> > Mathieu@: is it correct way to use proto enums?
> 
> if |generation_type| is of type
> AutofillUploadContents::Field::PasswordGenerationType, you wouldn't need the
> cast here (probably also wouldn't need the ::autofill:: since you are already
in
> the autofill namespace?)

Done.

[Mathieu, 2016-02-22 14:55:58]

Thanks Vadym! lgtm regarding all things proto/enums :)

[dvadym, 2016-02-23 09:58:03]

dvadym@chromium.org changed reviewers:
+ mkwst@chromium.org

[dvadym, 2016-02-23 09:58:04]

Hi Mike,

 Could you please review changes in IPC in autofill_messages.h?

Regards,
Vadym

[Mike West, 2016-02-23 10:02:01]

Adding these fields to the IPC LGTM.

That said, it's probably time to start thinking about migrating these to Mojo
(not in this CL. ;) )

[vabr (Chromium), 2016-02-23 10:03:13]

On 2016/02/23 10:02:01, Mike West wrote:
> Adding these fields to the IPC LGTM.
> 
> That said, it's probably time to start thinking about migrating these to Mojo
> (not in this CL. ;) )

Migrating to Mojo is http://crbug.com/582391 and being actively worked on. :)

[dvadym, 2016-02-23 10:33:24]

The CQ bit was checked by dvadym@chromium.org

[dvadym, 2016-02-23 10:33:25]

The patchset sent to the CQ was uploaded after l-g-t-m from vabr@chromium.org,
mathp@chromium.org
Link to the patchset: https://codereview.chromium.org/1686063004/#ps280001
(title: "Fix BUILD.gn")

[commit-bot: I haz the power, 2016-02-23 10:33:34]

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

[commit-bot: I haz the power, 2016-02-23 11:55:35]

Description was changed from

==========
Sending generated vote on password generation.

The generating of password by user is strong indication that the current form is
suitable for generation and we can use it for improving our heuristics.

This patch adds |generation_event| to uploaded field vote (in AutofillField
structure and in AutofillUploadContents proto) with information about generation
event which happened.

BUG=552420
==========

to

==========
Sending generated vote on password generation.

The generating of password by user is strong indication that the current form is
suitable for generation and we can use it for improving our heuristics.

This patch adds |generation_event| to uploaded field vote (in AutofillField
structure and in AutofillUploadContents proto) with information about generation
event which happened.

BUG=552420
==========

[commit-bot: I haz the power, 2016-02-23 11:55:35]

Committed patchset #15 (id:280001)

[commit-bot: I haz the power, 2016-02-23 11:57:09]

Description was changed from

==========
Sending generated vote on password generation.

The generating of password by user is strong indication that the current form is
suitable for generation and we can use it for improving our heuristics.

This patch adds |generation_event| to uploaded field vote (in AutofillField
structure and in AutofillUploadContents proto) with information about generation
event which happened.

BUG=552420
==========

to

==========
Sending generated vote on password generation.

The generating of password by user is strong indication that the current form is
suitable for generation and we can use it for improving our heuristics.

This patch adds |generation_event| to uploaded field vote (in AutofillField
structure and in AutofillUploadContents proto) with information about generation
event which happened.

BUG=552420

Committed: https://crrev.com/c0a523a2e2d85e487c3aa32ad57ac1a3e4694d46
Cr-Commit-Position: refs/heads/master@{#376968}
==========

[commit-bot: I haz the power, 2016-02-23 11:57:09]

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