Exposes passwordSavingEnabled API from chrome privacy preference extension.

Exposes passwordSavingEnabled API from chrome privacy preference extension.

This provides the following APIs at JavaScript level to enable/disable
password saving.

chrome.privacy.services.passwordSavingEnabled.get()
chrome.privacy.services.passwordSavingEnabled.set()
chrome.privacy.services.passwordSavingEnabled.clear()

R=bauerb@chromium.org, gcasto@chromium.org, koz@chromium.org, sabineb@google.com
BUG=61621
Committed: https://src.chromium.org/viewvc/chrome?view=rev&revision=279363

[ziran.sun, 2014-05-16 10:57:36]

Please review. Thanks!

[ziran.sun, 2014-05-19 08:45:27]

Please review. Thanks!

[Bernhard Bauer, 2014-05-19 11:32:07]

In general, it's sufficient to pick one of the OWNERS to review, not all of
them.

https://codereview.chromium.org/290123003/diff/1/chrome/browser/extensions/ap...
File chrome/browser/extensions/api/preference/preference_api.cc (right):

https://codereview.chromium.org/290123003/diff/1/chrome/browser/extensions/ap...
chrome/browser/extensions/api/preference/preference_api.cc:75:
{"passwordManagerEnabled", password_manager::prefs::kPasswordManagerEnabled,
These should be sorted by the first term, i.e. this should come before "proxy".

https://codereview.chromium.org/290123003/diff/1/chrome/common/extensions/api...
File chrome/common/extensions/api/privacy.json (right):

https://codereview.chromium.org/290123003/diff/1/chrome/common/extensions/api...
chrome/common/extensions/api/privacy.json:40: "description": "If disable,
password manager will no longer ask if you want to save passwords but will
continue to fill passwords. This preference's value is a boolean, defaulting to
<code>true</code>."
Descriptions should be positive, i.e. "If enabled, the password manager will ask
to save passwords. [...]"

[ziran.sun, 2014-05-19 14:14:35]

Update code as per review comments. All comments have been addressed. Please
review. Thanks!

[Bernhard Bauer, 2014-05-19 14:19:05]

https://codereview.chromium.org/290123003/diff/10001/chrome/common/extensions...
File chrome/common/extensions/api/privacy.json (right):

https://codereview.chromium.org/290123003/diff/10001/chrome/common/extensions...
chrome/common/extensions/api/privacy.json:39: "value":
["passwordManagerEnabled", {"type":"boolean"}],
Now that I think about it, do we want to change this name so it states that
*saving* passwords is enabled?

[ziran.sun, 2014-05-19 15:13:03]

On 2014/05/19 14:19:05, Bernhard Bauer wrote:
>
https://codereview.chromium.org/290123003/diff/10001/chrome/common/extensions...
> File chrome/common/extensions/api/privacy.json (right):
> 
>
https://codereview.chromium.org/290123003/diff/10001/chrome/common/extensions...
> chrome/common/extensions/api/privacy.json:39: "value":
> ["passwordManagerEnabled", {"type":"boolean"}],
> Now that I think about it, do we want to change this name so it states that
> *saving* passwords is enabled?

"passwordManagerEnabled" is to record new passwords and fill in known passwords.
For now, only "saving password" prompt is disabled when it's false but we
probably will introduce "disable password filling" in a later stage (I think the
code change will be on PasswordManager side). I probably will keep this name as
it is. Do let me know if I missed anything though. Thanks!

[Bernhard Bauer, 2014-05-19 15:31:30]

On 2014/05/19 15:13:03, ziran.sun wrote:
> On 2014/05/19 14:19:05, Bernhard Bauer wrote:
> >
>
https://codereview.chromium.org/290123003/diff/10001/chrome/common/extensions...
> > File chrome/common/extensions/api/privacy.json (right):
> > 
> >
>
https://codereview.chromium.org/290123003/diff/10001/chrome/common/extensions...
> > chrome/common/extensions/api/privacy.json:39: "value":
> > ["passwordManagerEnabled", {"type":"boolean"}],
> > Now that I think about it, do we want to change this name so it states that
> > *saving* passwords is enabled?
> 
> "passwordManagerEnabled" is to record new passwords and fill in known
passwords.
> For now, only "saving password" prompt is disabled when it's false but we
> probably will introduce "disable password filling" in a later stage 

Hm, I would suggest putting that behind a separate preference (and a separate
option in the extension API), otherwise you'll change the semantics of the
existing one. Then if we have two preferences, one for saving passwords, and one
for filling them in, it would make sense to give them names that state what
they're doing.

Or to put it another way, it's true that if "passwordManagerEnabled" is set to
true, we will both save passwords and fill them in, but if it's set to false, we
will still fill them, so what this preference turns off is saving passwords. If
additional functionality is added later to also turn off password filling,
clients of the API can simply disable both. If we change the semantics of the
existing option, it's more difficult for clients to work around that.

> (I think the
> code change will be on PasswordManager side). I probably will keep this name
as
> it is. Do let me know if I missed anything though. Thanks!

[ziran.sun, 2014-05-19 15:43:54]

On 2014/05/19 15:31:30, Bernhard Bauer wrote:
> On 2014/05/19 15:13:03, ziran.sun wrote:
> > On 2014/05/19 14:19:05, Bernhard Bauer wrote:
> > >
> >
>
https://codereview.chromium.org/290123003/diff/10001/chrome/common/extensions...
> > > File chrome/common/extensions/api/privacy.json (right):
> > > 
> > >
> >
>
https://codereview.chromium.org/290123003/diff/10001/chrome/common/extensions...
> > > chrome/common/extensions/api/privacy.json:39: "value":
> > > ["passwordManagerEnabled", {"type":"boolean"}],
> > > Now that I think about it, do we want to change this name so it states
that
> > > *saving* passwords is enabled?
> > 
> > "passwordManagerEnabled" is to record new passwords and fill in known
> passwords.
> > For now, only "saving password" prompt is disabled when it's false but we
> > probably will introduce "disable password filling" in a later stage 
> 
> Hm, I would suggest putting that behind a separate preference (and a separate
> option in the extension API), otherwise you'll change the semantics of the
> existing one. Then if we have two preferences, one for saving passwords, and
one
> for filling them in, it would make sense to give them names that state what
> they're doing.
> 
> Or to put it another way, it's true that if "passwordManagerEnabled" is set to
> true, we will both save passwords and fill them in, but if it's set to false,
we
> will still fill them, so what this preference turns off is saving passwords.
If
> additional functionality is added later to also turn off password filling,
> clients of the API can simply disable both. If we change the semantics of the
> existing option, it's more difficult for clients to work around that.
> 
> > (I think the
> > code change will be on PasswordManager side). I probably will keep this name
> as
> > it is. Do let me know if I missed anything though. Thanks!

It's a good point. Since "disable filling in password" is in the plan, I will
have a look on the code requested in PasswordManager side. In this case, when
"passwordManagerEnabled" is set as false, it will disable both "saving" and
"filling". Does this sound reasonable?

[Bernhard Bauer, 2014-05-19 15:51:23]

On 2014/05/19 15:43:54, ziran.sun wrote:
> On 2014/05/19 15:31:30, Bernhard Bauer wrote:
> > On 2014/05/19 15:13:03, ziran.sun wrote:
> > > On 2014/05/19 14:19:05, Bernhard Bauer wrote:
> > > >
> > >
> >
>
https://codereview.chromium.org/290123003/diff/10001/chrome/common/extensions...
> > > > File chrome/common/extensions/api/privacy.json (right):
> > > > 
> > > >
> > >
> >
>
https://codereview.chromium.org/290123003/diff/10001/chrome/common/extensions...
> > > > chrome/common/extensions/api/privacy.json:39: "value":
> > > > ["passwordManagerEnabled", {"type":"boolean"}],
> > > > Now that I think about it, do we want to change this name so it states
> that
> > > > *saving* passwords is enabled?
> > > 
> > > "passwordManagerEnabled" is to record new passwords and fill in known
> > passwords.
> > > For now, only "saving password" prompt is disabled when it's false but we
> > > probably will introduce "disable password filling" in a later stage 
> > 
> > Hm, I would suggest putting that behind a separate preference (and a
separate
> > option in the extension API), otherwise you'll change the semantics of the
> > existing one. Then if we have two preferences, one for saving passwords, and
> one
> > for filling them in, it would make sense to give them names that state what
> > they're doing.
> > 
> > Or to put it another way, it's true that if "passwordManagerEnabled" is set
to
> > true, we will both save passwords and fill them in, but if it's set to
false,
> we
> > will still fill them, so what this preference turns off is saving passwords.
> If
> > additional functionality is added later to also turn off password filling,
> > clients of the API can simply disable both. If we change the semantics of
the
> > existing option, it's more difficult for clients to work around that.
> > 
> > > (I think the
> > > code change will be on PasswordManager side). I probably will keep this
name
> > as
> > > it is. Do let me know if I missed anything though. Thanks!
> 
> It's a good point. Since "disable filling in password" is in the plan, I will
> have a look on the code requested in PasswordManager side. In this case, when
> "passwordManagerEnabled" is set as false, it will disable both "saving" and
> "filling". Does this sound reasonable?

It still seems weird to me to have one API to turn off A and B, and another API
to turn off just B. Why can't we have two orthogonal APIs that turn off A and B,
respectively?

In addition, if we land this as it is today, the behavior of
passwordManagerEnabled will change when you have implemented disabling filling
in passwords, which doesn't seem desirable.

In any case, if you feel strongly about this, I would suggest pulling in an
extension API OWNER (which I am not, so you'll need to do that at some point
anyway).

[ziran.sun, 2014-05-19 16:27:08]

On 2014/05/19 15:51:23, Bernhard Bauer wrote:
> On 2014/05/19 15:43:54, ziran.sun wrote:
> > On 2014/05/19 15:31:30, Bernhard Bauer wrote:
> > > On 2014/05/19 15:13:03, ziran.sun wrote:
> > > > On 2014/05/19 14:19:05, Bernhard Bauer wrote:
> > > > >
> > > >
> > >
> >
>
https://codereview.chromium.org/290123003/diff/10001/chrome/common/extensions...
> > > > > File chrome/common/extensions/api/privacy.json (right):
> > > > > 
> > > > >
> > > >
> > >
> >
>
https://codereview.chromium.org/290123003/diff/10001/chrome/common/extensions...
> > > > > chrome/common/extensions/api/privacy.json:39: "value":
> > > > > ["passwordManagerEnabled", {"type":"boolean"}],
> > > > > Now that I think about it, do we want to change this name so it states
> > that
> > > > > *saving* passwords is enabled?
> > > > 
> > > > "passwordManagerEnabled" is to record new passwords and fill in known
> > > passwords.
> > > > For now, only "saving password" prompt is disabled when it's false but
we
> > > > probably will introduce "disable password filling" in a later stage 
> > > 
> > > Hm, I would suggest putting that behind a separate preference (and a
> separate
> > > option in the extension API), otherwise you'll change the semantics of the
> > > existing one. Then if we have two preferences, one for saving passwords,
and
> > one
> > > for filling them in, it would make sense to give them names that state
what
> > > they're doing.
> > > 
> > > Or to put it another way, it's true that if "passwordManagerEnabled" is
set
> to
> > > true, we will both save passwords and fill them in, but if it's set to
> false,
> > we
> > > will still fill them, so what this preference turns off is saving
passwords.
> > If
> > > additional functionality is added later to also turn off password filling,
> > > clients of the API can simply disable both. If we change the semantics of
> the
> > > existing option, it's more difficult for clients to work around that.
> > > 
> > > > (I think the
> > > > code change will be on PasswordManager side). I probably will keep this
> name
> > > as
> > > > it is. Do let me know if I missed anything though. Thanks!
> > 
> > It's a good point. Since "disable filling in password" is in the plan, I
will
> > have a look on the code requested in PasswordManager side. In this case,
when
> > "passwordManagerEnabled" is set as false, it will disable both "saving" and
> > "filling". Does this sound reasonable?
> 
> It still seems weird to me to have one API to turn off A and B, and another
API
> to turn off just B. Why can't we have two orthogonal APIs that turn off A and
B,
> respectively?
> 

passwordManagerEnabled itself in PasswordManager should enable "saving" and
"filling" if it's true. I will check with Garrett and see what's his opinion on
introducing two APIs.

> In addition, if we land this as it is today, the behavior of
> passwordManagerEnabled will change when you have implemented disabling filling
> in passwords, which doesn't seem desirable.
> 
Since I'm thinking implemented disabling filling, I wasn't thinking about
landing this today.


> In any case, if you feel strongly about this, I would suggest pulling in an
> extension API OWNER (which I am not, so you'll need to do that at some point
> anyway).

I've added koz as the owner reviewer.

[ziran.sun, 2014-05-23 09:59:46]

Rebased code and renamed extension API. Please review. Thanks!

[Bernhard Bauer, 2014-05-23 10:10:22]

Thanks! Could you please also update the CL description?

https://codereview.chromium.org/290123003/diff/30001/chrome/common/extensions...
File chrome/common/extensions/api/privacy.json (right):

https://codereview.chromium.org/290123003/diff/30001/chrome/common/extensions...
chrome/common/extensions/api/privacy.json:40: "description": "If enabled,
password manager will ask if you want to save passwords. This preference's value
is a boolean, defaulting to <code>true</code>."
Nit: "the password manager".

[ziran.sun, 2014-05-23 10:32:24]

Updated documentation as per Bernhard's review comments. Thanks!

[Bernhard Bauer, 2014-05-23 10:49:46]

LGTM with two description nits:

1. It would be good to also update the CL subject.
2. Previously, PasswordManager refered to a class of that name. PasswordSaving
is not a class, so would replace "PasswordSaving service" with plain "password
saving".

[ziran.sun, 2014-05-23 10:52:31]

On 2014/05/23 10:49:46, Bernhard Bauer wrote:
> LGTM with two description nits:
> 
> 1. It would be good to also update the CL subject.
> 2. Previously, PasswordManager refered to a class of that name. PasswordSaving
> is not a class, so would replace "PasswordSaving service" with plain "password
> saving".

Done. Thanks very much!

[koz (OOO until 15th September), 2014-05-25 23:27:25]

lgtm

[battre, 2014-05-26 07:49:52]

Just a quick check: Do we want this under the privacy permission?

[Garrett Casto, 2014-05-27 04:48:33]

On 2014/05/26 07:49:52, battre wrote:
> Just a quick check: Do we want this under the privacy permission?

I asked this same question, though it looks like it was off list. This feature
doesn't make any requests to third party services, which makes it different from
everything else in this package as far as I can tell. However, I'm not sure
where it would go otherwise.

[ziran.sun, 2014-06-02 09:47:29]

On 2014/05/27 04:48:33, Garrett Casto wrote:
> On 2014/05/26 07:49:52, battre wrote:
> > Just a quick check: Do we want this under the privacy permission?
> 
> I asked this same question, though it looks like it was off list. This feature
> doesn't make any requests to third party services, which makes it different
from
> everything else in this package as far as I can tell. However, I'm not sure
> where it would go otherwise.

Any suggestion on how we move this forward? If no suggestions on a better place
to put this, can I assume that leaving it under the privacy permission is okay?

[battre, 2014-06-02 09:56:10]

+kalman

Ben, WDYT of adding a new api chrome.passwords just for this one feature? I
think that chrome.privacy might be the wrong place (wrong permission request)
but I don't know whether we want to add a new API for which we have no
additional plans.

Best regards,
Dominic

[not at google - send to devlin, 2014-06-02 17:28:40]

On 2014/06/02 09:56:10, battre wrote:
> +kalman
> 
> Ben, WDYT of adding a new api chrome.passwords just for this one feature? I
> think that chrome.privacy might be the wrong place (wrong permission request)
> but I don't know whether we want to add a new API for which we have no
> additional plans.
> 
> Best regards,
> Dominic

It seems fine in chrome.privacy? What is the permission warning there?

+meacer/jww.

[meacer, 2014-06-02 17:51:05]

On 2014/06/02 17:28:40, kalman wrote:
> On 2014/06/02 09:56:10, battre wrote:
> > +kalman
> > 
> > Ben, WDYT of adding a new api chrome.passwords just for this one feature? I
> > think that chrome.privacy might be the wrong place (wrong permission
request)
> > but I don't know whether we want to add a new API for which we have no
> > additional plans.
> > 
> > Best regards,
> > Dominic
> 
> It seems fine in chrome.privacy? What is the permission warning there?
> 
> +meacer/jww.

"Manipulate privacy-related settings" for chrome.privacy

[ziran.sun, 2014-06-05 16:55:37]

On 2014/06/02 17:51:05, Mustafa Emre Acer wrote:
> On 2014/06/02 17:28:40, kalman wrote:
> > On 2014/06/02 09:56:10, battre wrote:
> > > +kalman
> > > 
> > > Ben, WDYT of adding a new api chrome.passwords just for this one feature?
I
> > > think that chrome.privacy might be the wrong place (wrong permission
> request)
> > > but I don't know whether we want to add a new API for which we have no
> > > additional plans.
> > > 
> > > Best regards,
> > > Dominic
> > 
> > It seems fine in chrome.privacy? What is the permission warning there?
> > 
> > +meacer/jww.
> 
> "Manipulate privacy-related settings" for chrome.privacy

Kalman, battre, meacer - thanks very much for the information. Any further
suggestion what I can do to move this forward?

[jww, 2014-06-16 18:14:05]

lgtm

[not at google - send to devlin, 2014-06-16 18:39:54]

I would like battre@ to look at this API before it gets submitted.

[battre, 2014-06-18 14:47:22]

On 2014/06/16 18:39:54, kalman wrote:
> I would like battre@ to look at this API before it gets submitted.

I looked at this and the implementation and the idea of allowing to disable the
password manager from an extension are both fine with me.

I am torn whether chrome.privacy is the right namespace. The setting is not
exposed in chrome://settings under the privacy section and has no relationship
with privacy except that we don't have a better namespace at the moment.

[Ilya Sherman, 2014-06-20 20:27:48]

On 2014/06/18 14:47:22, battre wrote:
> On 2014/06/16 18:39:54, kalman wrote:
> > I would like battre@ to look at this API before it gets submitted.
> 
> I looked at this and the implementation and the idea of allowing to disable
the
> password manager from an extension are both fine with me.
> 
> I am torn whether chrome.privacy is the right namespace. The setting is not
> exposed in chrome://settings under the privacy section and has no relationship
> with privacy except that we don't have a better namespace at the moment.

Note that the autofillEnabled setting is currently exposed through this same
namespace.  IMO it makes sense to keep the two settings together.  Whether there
is a more appropriate namespace for both of them is beyond my ken.

[battre, 2014-06-23 14:42:57]

On 2014/06/20 20:27:48, Ilya Sherman wrote:
> On 2014/06/18 14:47:22, battre wrote:
> > On 2014/06/16 18:39:54, kalman wrote:
> > > I would like battre@ to look at this API before it gets submitted.
> > 
> > I looked at this and the implementation and the idea of allowing to disable
> the
> > password manager from an extension are both fine with me.
> > 
> > I am torn whether chrome.privacy is the right namespace. The setting is not
> > exposed in chrome://settings under the privacy section and has no
relationship
> > with privacy except that we don't have a better namespace at the moment.
> 
> Note that the autofillEnabled setting is currently exposed through this same
> namespace.  IMO it makes sense to keep the two settings together.  Whether
there
> is a more appropriate namespace for both of them is beyond my ken.

This is good to know. In this case I agree that we should keep it here. LGTM.

[not at google - send to devlin, 2014-06-23 14:46:11]

lgtm

[ziran.sun, 2014-06-23 14:50:14]

On 2014/06/23 14:46:11, kalman wrote:
> lgtm

Can I commit this patch in now?

[not at google - send to devlin, 2014-06-23 14:52:55]

yes

[ziran.sun, 2014-06-23 14:56:36]

The CQ bit was checked by ziran.sun@samsung.com

[commit-bot: I haz the power, 2014-06-23 14:57:26]

CQ is trying da patch. Follow status at
 https://chromium-status.appspot.com/cq/ziran.sun@samsung.com/290123003/50001

[commit-bot: I haz the power, 2014-06-23 15:11:33]

FYI, CQ is re-trying this CL (attempt #1).
The failing builders are:
  android_aosp on tryserver.chromium
(http://build.chromium.org/p/tryserver.chromium/builders/android_aosp/builds/8...)
  android_chromium_gn_compile_rel on tryserver.chromium
(http://build.chromium.org/p/tryserver.chromium/builders/android_chromium_gn_c...)
  android_clang_dbg on tryserver.chromium
(http://build.chromium.org/p/tryserver.chromium/builders/android_clang_dbg/bui...)
  android_dbg on tryserver.chromium
(http://build.chromium.org/p/tryserver.chromium/builders/android_dbg/builds/19...)
  chromium_presubmit on tryserver.chromium
(http://build.chromium.org/p/tryserver.chromium/builders/chromium_presubmit/bu...)
  ios_dbg_simulator on tryserver.chromium
(http://build.chromium.org/p/tryserver.chromium/builders/ios_dbg_simulator/bui...)
  ios_rel_device on tryserver.chromium
(http://build.chromium.org/p/tryserver.chromium/builders/ios_rel_device/builds...)
  ios_rel_device_ninja on tryserver.chromium
(http://build.chromium.org/p/tryserver.chromium/builders/ios_rel_device_ninja/...)
  linux_chromium_chromeos_clang_dbg on tryserver.chromium
(http://build.chromium.org/p/tryserver.chromium/builders/linux_chromium_chrome...)
  linux_chromium_chromeos_rel on tryserver.chromium
(http://build.chromium.org/p/tryserver.chromium/builders/linux_chromium_chrome...)
  linux_chromium_clang_dbg on tryserver.chromium
(http://build.chromium.org/p/tryserver.chromium/builders/linux_chromium_clang_...)
  linux_chromium_gn_rel on tryserver.chromium
(http://build.chromium.org/p/tryserver.chromium/builders/linux_chromium_gn_rel...)
  linux_chromium_rel on tryserver.chromium
(http://build.chromium.org/p/tryserver.chromium/builders/linux_chromium_rel/bu...)
  mac_chromium_compile_dbg on tryserver.chromium
(http://build.chromium.org/p/tryserver.chromium/builders/mac_chromium_compile_...)
  mac_chromium_rel on tryserver.chromium
(http://build.chromium.org/p/tryserver.chromium/builders/mac_chromium_rel/buil...)
  win_chromium_compile_dbg on tryserver.chromium
(http://build.chromium.org/p/tryserver.chromium/builders/win_chromium_compile_...)
  win_chromium_rel on tryserver.chromium
(http://build.chromium.org/p/tryserver.chromium/builders/win_chromium_rel/buil...)
  win_chromium_x64_rel on tryserver.chromium
(http://build.chromium.org/p/tryserver.chromium/builders/win_chromium_x64_rel/...)
  linux_gpu on tryserver.chromium.gpu
(http://build.chromium.org/p/tryserver.chromium.gpu/builders/linux_gpu/builds/...)
  mac_gpu on tryserver.chromium.gpu
(http://build.chromium.org/p/tryserver.chromium.gpu/builders/mac_gpu/builds/20352)
  win_gpu on tryserver.chromium.gpu
(http://build.chromium.org/p/tryserver.chromium.gpu/builders/win_gpu/builds/24183)

[commit-bot: I haz the power, 2014-06-23 15:13:06]

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

[commit-bot: I haz the power, 2014-06-23 15:13:07]

Try jobs failed on following builders:
  mac_gpu on tryserver.chromium.gpu
(http://build.chromium.org/p/tryserver.chromium.gpu/builders/mac_gpu/builds/20358)

[ziran.sun, 2014-06-23 17:15:09]

The CQ bit was checked by ziran.sun@samsung.com

[commit-bot: I haz the power, 2014-06-23 17:15:58]

CQ is trying da patch. Follow status at
 https://chromium-status.appspot.com/cq/ziran.sun@samsung.com/290123003/70001

[commit-bot: I haz the power, 2014-06-23 19:02:37]

FYI, CQ is re-trying this CL (attempt #1).
The failing builders are:
  chromium_presubmit on tryserver.chromium
(http://build.chromium.org/p/tryserver.chromium/builders/chromium_presubmit/bu...)

[commit-bot: I haz the power, 2014-06-23 19:11:43]

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

[commit-bot: I haz the power, 2014-06-23 19:11:44]

Try jobs failed on following builders:
  chromium_presubmit on tryserver.chromium
(http://build.chromium.org/p/tryserver.chromium/builders/chromium_presubmit/bu...)

[ziran.sun, 2014-06-24 08:56:10]

The CQ bit was checked by ziran.sun@samsung.com

[commit-bot: I haz the power, 2014-06-24 08:57:06]

CQ is trying da patch. Follow status at
 https://chromium-status.appspot.com/cq/ziran.sun@samsung.com/290123003/70001

[commit-bot: I haz the power, 2014-06-24 08:59:00]

Change committed as 279363