Initial implementation of music manager private API.

Initial implementation of music manager private API.

MacOS and Linux are currently not supported. This will come in a later CL.

BUG=242540
Committed: https://src.chromium.org/viewvc/chrome?view=rev&revision=202929

[rpaquay, 2013-05-22 18:21:13]

Reviewers,

This is the initial implementation of the music manager private API (see
referenced BUG).

mpcomplete@
  all files: for owner review

drewry@, battre@
  chrome/browser/extensions/api/music_manager_private/device_id.cc: for security
review (correct use of rlz, salt and hmac)

Thanks,
Renaud

[Matt Perry, 2013-05-22 21:08:31]

Has this gone through API review?
http://dev.chromium.org/developers/design-documents/extensions/proposed-chang...

[Matt Perry, 2013-05-22 21:18:02]

https://codereview.chromium.org/15738013/diff/4001/chrome/common/extensions/a...
File chrome/common/extensions/api/music_manager_private.idl (right):

https://codereview.chromium.org/15738013/diff/4001/chrome/common/extensions/a...
chrome/common/extensions/api/music_manager_private.idl:5: namespace
musicManagerPrivate {
put [nodoc] before namespace, and it'll apply globally

[Matt Perry, 2013-05-22 22:19:11]

https://codereview.chromium.org/15738013/diff/4001/chrome/browser/extensions/...
File chrome/browser/extensions/api/music_manager_private/device_id.h (right):

https://codereview.chromium.org/15738013/diff/4001/chrome/browser/extensions/...
chrome/browser/extensions/api/music_manager_private/device_id.h:8: #include
"string"
<string>

https://codereview.chromium.org/15738013/diff/4001/chrome/browser/extensions/...
chrome/browser/extensions/api/music_manager_private/device_id.h:12: std::string
GetDeviceID(const std::string& salt);
Comment this. Especially if this needs to be called on a particular thread.

https://codereview.chromium.org/15738013/diff/4001/chrome/browser/extensions/...
File
chrome/browser/extensions/api/music_manager_private/music_manager_private_api.cc
(right):

https://codereview.chromium.org/15738013/diff/4001/chrome/browser/extensions/...
chrome/browser/extensions/api/music_manager_private/music_manager_private_api.cc:31:
void  MusicManagerPrivateGetDeviceIdFunction::ComputeOnIOThread() {
Why does this need to be done on the IO thread?

https://codereview.chromium.org/15738013/diff/4001/chrome/browser/extensions/...
chrome/browser/extensions/api/music_manager_private/music_manager_private_api.cc:38:
SetError("Device ID API is not supported on this platform.");
move this to a constant at the top of the file.

https://codereview.chromium.org/15738013/diff/4001/chrome/browser/extensions/...
chrome/browser/extensions/api/music_manager_private/music_manager_private_api.cc:45:
content::BrowserThread::PostTask(content::BrowserThread::IO, FROM_HERE,
you want to post this to the UI thread

https://codereview.chromium.org/15738013/diff/4001/chrome/browser/extensions/...
File
chrome/browser/extensions/api/music_manager_private/music_manager_private_browsertest.cc
(right):

https://codereview.chromium.org/15738013/diff/4001/chrome/browser/extensions/...
chrome/browser/extensions/api/music_manager_private/music_manager_private_browsertest.cc:7:
#include "chrome/common/chrome_switches.h"
this include not needed?

https://codereview.chromium.org/15738013/diff/4001/chrome/common/extensions/a...
File chrome/common/extensions/api/_permission_features.json (right):

https://codereview.chromium.org/15738013/diff/4001/chrome/common/extensions/a...
chrome/common/extensions/api/_permission_features.json:339: "extension_types":
["platform_app"]
add the whitelist of IDs here (or better yet, the SHA1 of the ids).

[rpaquay, 2013-05-22 23:55:50]

Address Matt's code review feedback.

https://codereview.chromium.org/15738013/diff/4001/chrome/browser/extensions/...
File chrome/browser/extensions/api/music_manager_private/device_id.h (right):

https://codereview.chromium.org/15738013/diff/4001/chrome/browser/extensions/...
chrome/browser/extensions/api/music_manager_private/device_id.h:8: #include
"string"
On 2013/05/22 22:19:11, Matt Perry wrote:
> <string>

Done.

https://codereview.chromium.org/15738013/diff/4001/chrome/browser/extensions/...
chrome/browser/extensions/api/music_manager_private/device_id.h:12: std::string
GetDeviceID(const std::string& salt);
On 2013/05/22 22:19:11, Matt Perry wrote:
> Comment this. Especially if this needs to be called on a particular thread.

Done.

https://codereview.chromium.org/15738013/diff/4001/chrome/browser/extensions/...
File
chrome/browser/extensions/api/music_manager_private/music_manager_private_api.cc
(right):

https://codereview.chromium.org/15738013/diff/4001/chrome/browser/extensions/...
chrome/browser/extensions/api/music_manager_private/music_manager_private_api.cc:31:
void  MusicManagerPrivateGetDeviceIdFunction::ComputeOnIOThread() {
On 2013/05/22 22:19:11, Matt Perry wrote:
> Why does this need to be done on the IO thread?
I am not 100% sure. This code is inspired from
DeviceIDFetcher::ComputeOnIOThread in
chrome/browser/renderer_host/pepper/device_id_fetcher.cc, which is run on the IO
thread. The only explanation I have is that we don't want to run this on the UI
thread because the operation may be CPU intensive. There might be other reasons.

https://codereview.chromium.org/15738013/diff/4001/chrome/browser/extensions/...
chrome/browser/extensions/api/music_manager_private/music_manager_private_api.cc:38:
SetError("Device ID API is not supported on this platform.");
On 2013/05/22 22:19:11, Matt Perry wrote:
> move this to a constant at the top of the file.

Done.

https://codereview.chromium.org/15738013/diff/4001/chrome/browser/extensions/...
chrome/browser/extensions/api/music_manager_private/music_manager_private_api.cc:45:
content::BrowserThread::PostTask(content::BrowserThread::IO, FROM_HERE,
On 2013/05/22 22:19:11, Matt Perry wrote:
> you want to post this to the UI thread
Sorry, last minute typo. Done.

https://codereview.chromium.org/15738013/diff/4001/chrome/browser/extensions/...
File
chrome/browser/extensions/api/music_manager_private/music_manager_private_browsertest.cc
(right):

https://codereview.chromium.org/15738013/diff/4001/chrome/browser/extensions/...
chrome/browser/extensions/api/music_manager_private/music_manager_private_browsertest.cc:7:
#include "chrome/common/chrome_switches.h"
On 2013/05/22 22:19:11, Matt Perry wrote:
> this include not needed?
No, it is a leftover from a previous version of the test. Removed.

https://codereview.chromium.org/15738013/diff/4001/chrome/common/extensions/a...
File chrome/common/extensions/api/_permission_features.json (right):

https://codereview.chromium.org/15738013/diff/4001/chrome/common/extensions/a...
chrome/common/extensions/api/_permission_features.json:339: "extension_types":
["platform_app"]
On 2013/05/22 22:19:11, Matt Perry wrote:
> add the whitelist of IDs here (or better yet, the SHA1 of the ids).

Done.

https://codereview.chromium.org/15738013/diff/4001/chrome/common/extensions/a...
File chrome/common/extensions/api/music_manager_private.idl (right):

https://codereview.chromium.org/15738013/diff/4001/chrome/common/extensions/a...
chrome/common/extensions/api/music_manager_private.idl:5: namespace
musicManagerPrivate {
On 2013/05/22 21:18:03, Matt Perry wrote:
> put [nodoc] before namespace, and it'll apply globally

Done.

[Matt Perry, 2013-05-23 00:01:15]

https://codereview.chromium.org/15738013/diff/4001/chrome/browser/extensions/...
File
chrome/browser/extensions/api/music_manager_private/music_manager_private_api.cc
(right):

https://codereview.chromium.org/15738013/diff/4001/chrome/browser/extensions/...
chrome/browser/extensions/api/music_manager_private/music_manager_private_api.cc:31:
void  MusicManagerPrivateGetDeviceIdFunction::ComputeOnIOThread() {
On 2013/05/22 23:55:50, rpaquay wrote:
> On 2013/05/22 22:19:11, Matt Perry wrote:
> > Why does this need to be done on the IO thread?
> I am not 100% sure. This code is inspired from
> DeviceIDFetcher::ComputeOnIOThread in
> chrome/browser/renderer_host/pepper/device_id_fetcher.cc, which is run on the
IO
> thread. The only explanation I have is that we don't want to run this on the
UI
> thread because the operation may be CPU intensive. There might be other
reasons.

Could you please doublecheck with the author of that code? If this is
computationally intensive, it's not a good idea to block the IO thread either.
It would be better to put it on a WorkerPool.

[battre, 2013-05-23 09:44:16]

lgtm

https://codereview.chromium.org/15738013/diff/16001/chrome/browser/extensions...
File
chrome/browser/extensions/api/music_manager_private/music_manager_private_api.cc
(right):

https://codereview.chromium.org/15738013/diff/16001/chrome/browser/extensions...
chrome/browser/extensions/api/music_manager_private/music_manager_private_api.cc:13:

nit: remove newline?

https://codereview.chromium.org/15738013/diff/16001/chrome/browser/extensions...
chrome/browser/extensions/api/music_manager_private/music_manager_private_api.cc:21:
MusicManagerPrivateGetDeviceIdFunction() {
nit: -2 spaces? (also below)

[raymes, 2013-05-23 16:37:22]

Does this tie into any of the existing privacy prefs for the device ID?

prefs::kEnableDRM is hooked up to a UI setting which allows the user to control
whether or not they expose a device ID. This seems like it could be hooked up
here.

prefs::kDRMSalt is a per-profile (resettable) salt used in generation of the
device ID for Flash DRM. This may or may not be relevant here depending on the
requirements.

[rpaquay, 2013-05-23 17:00:26]

On 2013/05/23 16:37:22, raymes wrote:
> Does this tie into any of the existing privacy prefs for the device ID?
> 
> prefs::kEnableDRM is hooked up to a UI setting which allows the user to
control
> whether or not they expose a device ID. This seems like it could be hooked up
> here.
battre@, pludwig@, should this private API obey the kEnableDRM flag?


> prefs::kDRMSalt is a per-profile (resettable) salt used in generation of the
> device ID for Flash DRM. This may or may not be relevant here depending on the
> requirements.
I think our requirements prevent us from using per user/profile salt when
generating the ID.

[raymes1, 2013-05-23 17:13:02]

Ok thanks! Also, out of curiosity, has there been discussion with chrome-privacy
about this? I know we wanted to provide a more general API for exposing device
IDs rather than having N different APIs.

[rpaquay, 2013-05-23 17:40:38]

https://codereview.chromium.org/15738013/diff/16001/chrome/browser/extensions...
File
chrome/browser/extensions/api/music_manager_private/music_manager_private_api.cc
(right):

https://codereview.chromium.org/15738013/diff/16001/chrome/browser/extensions...
chrome/browser/extensions/api/music_manager_private/music_manager_private_api.cc:13:

On 2013/05/23 09:44:16, battre wrote:
> nit: remove newline?

Done.

https://codereview.chromium.org/15738013/diff/16001/chrome/browser/extensions...
chrome/browser/extensions/api/music_manager_private/music_manager_private_api.cc:21:
MusicManagerPrivateGetDeviceIdFunction() {
On 2013/05/23 09:44:16, battre wrote:
> nit: -2 spaces? (also below)

Done.

[rpaquay, 2013-05-23 19:39:46]

As of Patch Set #5, all comments so far have been addressed.

https://codereview.chromium.org/15738013/diff/4001/chrome/browser/extensions/...
File
chrome/browser/extensions/api/music_manager_private/music_manager_private_api.cc
(right):

https://codereview.chromium.org/15738013/diff/4001/chrome/browser/extensions/...
chrome/browser/extensions/api/music_manager_private/music_manager_private_api.cc:31:
void  MusicManagerPrivateGetDeviceIdFunction::ComputeOnIOThread() {
On 2013/05/23 00:01:15, Matt Perry wrote:
> On 2013/05/22 23:55:50, rpaquay wrote:
> > On 2013/05/22 22:19:11, Matt Perry wrote:
> > > Why does this need to be done on the IO thread?
> > I am not 100% sure. This code is inspired from
> > DeviceIDFetcher::ComputeOnIOThread in
> > chrome/browser/renderer_host/pepper/device_id_fetcher.cc, which is run on
the
> IO
> > thread. The only explanation I have is that we don't want to run this on the
> UI
> > thread because the operation may be CPU intensive. There might be other
> reasons.
> 
> Could you please doublecheck with the author of that code? If this is
> computationally intensive, it's not a good idea to block the IO thread either.
> It would be better to put it on a WorkerPool.

It turns our this computation is not expensive, so we can run the function on
the UI thread. Created new patchset with corresponding change.

[Matt Perry, 2013-05-23 19:42:26]

lgtm

[commit-bot: I haz the power, 2013-05-23 19:50:54]

CQ is trying da patch. Follow status at
https://chromium-status.appspot.com/cq/rpaquay@chromium.org/15738013/31001

[commit-bot: I haz the power, 2013-05-23 19:51:08]

Failed to apply patch for
chrome/browser/extensions/extension_function_histogram_value.h:
While running patch -p1 --forward --force --no-backup-if-mismatch;
  patching file chrome/browser/extensions/extension_function_histogram_value.h
  Hunk #1 FAILED at 528.
  1 out of 1 hunk FAILED -- saving rejects to file
chrome/browser/extensions/extension_function_histogram_value.h.rej

Patch:       chrome/browser/extensions/extension_function_histogram_value.h
Index: chrome/browser/extensions/extension_function_histogram_value.h
diff --git a/chrome/browser/extensions/extension_function_histogram_value.h
b/chrome/browser/extensions/extension_function_histogram_value.h
index
6c009b46f62e08d3e11e7e05549688b35c7d8331..8841c32318bbdb26c796a12353be207c30ad3837
100644
--- a/chrome/browser/extensions/extension_function_histogram_value.h
+++ b/chrome/browser/extensions/extension_function_histogram_value.h
@@ -528,6 +528,7 @@ enum HistogramValue {
   EXPERIMENTAL_ACCESSIBILITY_SETNATIVEACCESSIBILITYENABLED,
   RUNTIME_GETPLATFORMINFO,
   WEBVIEW_INSERTCSS,
+  MUSICMANAGERPRIVATE_GETDEVICEID,
   ENUM_BOUNDARY // Last entry: Add new entries above.
 };

[commit-bot: I haz the power, 2013-05-23 20:36:47]

CQ is trying da patch. Follow status at
https://chromium-status.appspot.com/cq/rpaquay@chromium.org/15738013/39001

[raymes1, 2013-05-23 21:17:21]

I'm curious: in what way here are the requirements different from the Flash
device ID?

It would have been nice if we could re-use
chrome/browser/renderer_host/pepper/device_id_fetcher.h and have everything be
unified. I've only skimmed over the code here but it looks extremely similar.
The only thing I see that might need to be added is an option so that the device
id is not per-profile.

[rpaquay, 2013-05-23 21:41:09]

On 2013/05/23 21:17:21, raymes1 wrote:
> I'm curious: in what way here are the requirements different from the Flash
> device ID?
> 
> It would have been nice if we could re-use
> chrome/browser/renderer_host/pepper/device_id_fetcher.h and have everything be
> unified. I've only skimmed over the code here but it looks extremely similar.
> The only thing I see that might need to be added is an option so that the
device
> id is not per-profile.

Other than the not per profile requirement, we would also like to support MacOS
and Linux if possible. We are still looking for the best way to implement a
proper device id on those platforms. Is there a reason we would not support
device id on these additional platforms?

[raymes1, 2013-05-23 21:48:47]

You should be able to implement other platforms in the existing code as well.
Currently we don't have them implemented for flash because it doesn't use them.

[commit-bot: I haz the power, 2013-05-23 23:35:54]

Retried try job too often on linux_chromeos for step(s) browser_tests
http://build.chromium.org/p/tryserver.chromium/buildstatus?builder=linux_chro...

[battre, 2013-05-24 07:22:38]

On 2013/05/23 17:00:26, rpaquay wrote:
> On 2013/05/23 16:37:22, raymes wrote:
> > Does this tie into any of the existing privacy prefs for the device ID?
> > 
> > prefs::kEnableDRM is hooked up to a UI setting which allows the user to
> control
> > whether or not they expose a device ID. This seems like it could be hooked
up
> > here.
> battre@, pludwig@, should this private API obey the kEnableDRM flag?

That flag is only exposed on ChromeOS and I think it would be good to honor it.
On other platforms, I would not add the flag into the chrome://settings UI
because it affects platform apps rather than chrome itself. It would be great to
have something similar in the Native Apps configuration. We definitely want a
solution once we implement an API that exceeds this workaround.

[commit-bot: I haz the power, 2013-05-24 17:29:17]

CQ is trying da patch. Follow status at
https://chromium-status.appspot.com/cq/rpaquay@chromium.org/15738013/57001

[commit-bot: I haz the power, 2013-05-24 17:29:24]

Failed to apply patch for
chrome/browser/extensions/extension_function_histogram_value.h:
While running patch -p1 --forward --force --no-backup-if-mismatch;
  patching file chrome/browser/extensions/extension_function_histogram_value.h
  Hunk #1 FAILED at 530.
  1 out of 1 hunk FAILED -- saving rejects to file
chrome/browser/extensions/extension_function_histogram_value.h.rej

Patch:       chrome/browser/extensions/extension_function_histogram_value.h
Index: chrome/browser/extensions/extension_function_histogram_value.h
diff --git a/chrome/browser/extensions/extension_function_histogram_value.h
b/chrome/browser/extensions/extension_function_histogram_value.h
index
44b709f0766fa633a1ec5c4c1a8675a6d7b9d982..e05d1c5c1a887f6f8d764029e4c0e8d245167488
100644
--- a/chrome/browser/extensions/extension_function_histogram_value.h
+++ b/chrome/browser/extensions/extension_function_histogram_value.h
@@ -530,6 +530,7 @@ enum HistogramValue {
   WEBVIEW_INSERTCSS,
   METRICSPRIVATE_GETISCRASHRECORDINGENABLED,
   IDENTITYPRIVATE_GETRESOURCES,
+  MUSICMANAGERPRIVATE_GETDEVICEID,
   ENUM_BOUNDARY // Last entry: Add new entries above.
 };

[rpaquay, 2013-05-25 00:06:22]

Path Set #9: Unification with Pepper device ID implementation.

raymes@:

* What do you think of the change to DeviceIDFetcher? This is the simplest
changed I could think of to unify both code path, but the result is not the
cleanest. I could create sub-classes or use a Delegate to handle the difference
in behavior, maybe? The main problem with unifying is handling the "salt": in
one case, it has to be read and written on the UI thread, on the other case, it
is known by the caller at construction time.

* Should we move the "device_id_fetcher.*" files to a different location? What
would you suggest?

Thanks,
Renaud

[raymes1, 2013-05-25 00:44:39]

https://codereview.chromium.org/15738013/diff/65001/chrome/browser/renderer_h...
File chrome/browser/renderer_host/pepper/device_id_fetcher.cc (right):

https://codereview.chromium.org/15738013/diff/65001/chrome/browser/renderer_h...
chrome/browser/renderer_host/pepper/device_id_fetcher.cc:35: const char
kDRMIdentifierFile[] = "Pepper DRM ID.0";
Can you copy this to pepper_device_id_host.cc and call it
kDRMIdentifierServiceName and pass it in on construction?

https://codereview.chromium.org/15738013/diff/65001/chrome/browser/renderer_h...
chrome/browser/renderer_host/pepper/device_id_fetcher.cc:50: const std::string&
salt)
Really we have 2 salts here. 1 is a per-profile salt (for pepper) and the other
is really per-service.

Could the constructor be:
DeviceIDFetcher(
int render_process_id, 
std::string service_name, 
std::string per_service_salt,
bool is_per_profile);

And then get rid of the other constructor. I'd also rename all the current
occurences of "salt" to "per_profile_salt"

https://codereview.chromium.org/15738013/diff/65001/chrome/browser/renderer_h...
chrome/browser/renderer_host/pepper/device_id_fetcher.cc:117: if
(IsPepperSpecific()) {
if (is_per_profile_)

https://codereview.chromium.org/15738013/diff/65001/chrome/browser/renderer_h...
chrome/browser/renderer_host/pepper/device_id_fetcher.cc:129: bool legacy =
IsPepperSpecific();
You wouldn't have to change any of this.

https://codereview.chromium.org/15738013/diff/65001/chrome/browser/renderer_h...
chrome/browser/renderer_host/pepper/device_id_fetcher.cc:151: 
Now add
combined_salt = per_service_salt + per_profile_salt_;

https://codereview.chromium.org/15738013/diff/65001/chrome/browser/renderer_h...
chrome/browser/renderer_host/pepper/device_id_fetcher.cc:156: (salt_.empty() &&
salt_bytes.size() != kSaltLength)) {
You wouldn't have to change this.

[rpaquay, 2013-05-28 17:56:01]

Addressing raymes@ code review feedback.

There are 2 additional changes needed after this (assuming we want to keep going
with the unification):
1) Move device_id_fetcher.* up one directory
2) Pass an additional option to ignore the "kEnableDRM" setting (for Chrome Apps
API).

https://codereview.chromium.org/15738013/diff/65001/chrome/browser/renderer_h...
File chrome/browser/renderer_host/pepper/device_id_fetcher.cc (right):

https://codereview.chromium.org/15738013/diff/65001/chrome/browser/renderer_h...
chrome/browser/renderer_host/pepper/device_id_fetcher.cc:50: const std::string&
salt)
On 2013/05/25 00:44:40, raymes1 wrote:
> Really we have 2 salts here. 1 is a per-profile salt (for pepper) and the
other
> is really per-service.
> 
> Could the constructor be:
> DeviceIDFetcher(
> int render_process_id, 
> std::string service_name, 
> std::string per_service_salt,
> bool is_per_profile);
> 
> And then get rid of the other constructor. I'd also rename all the current
> occurences of "salt" to "per_profile_salt"

Done.

https://codereview.chromium.org/15738013/diff/65001/chrome/browser/renderer_h...
chrome/browser/renderer_host/pepper/device_id_fetcher.cc:117: if
(IsPepperSpecific()) {
On 2013/05/25 00:44:40, raymes1 wrote:
> if (is_per_profile_)

Done.

https://codereview.chromium.org/15738013/diff/65001/chrome/browser/renderer_h...
chrome/browser/renderer_host/pepper/device_id_fetcher.cc:129: bool legacy =
IsPepperSpecific();
On 2013/05/25 00:44:40, raymes1 wrote:
> You wouldn't have to change any of this.
There is still a "is_per_profile_" check, because we never want to run the
legacy path for the new consumers.

https://codereview.chromium.org/15738013/diff/65001/chrome/browser/renderer_h...
chrome/browser/renderer_host/pepper/device_id_fetcher.cc:151: 
On 2013/05/25 00:44:40, raymes1 wrote:
> Now add
> combined_salt = per_service_salt + per_profile_salt_;

Done.

https://codereview.chromium.org/15738013/diff/65001/chrome/browser/renderer_h...
chrome/browser/renderer_host/pepper/device_id_fetcher.cc:156: (salt_.empty() &&
salt_bytes.size() != kSaltLength)) {
On 2013/05/25 00:44:40, raymes1 wrote:
> You wouldn't have to change this.

Done.

[rpaquay, 2013-05-28 20:42:22]

Finish unification work

1) move device_id_fetcher to its own directory
2) music manager private API does not obey kEnableDRM setting

[commit-bot: I haz the power, 2013-05-28 21:12:39]

CQ is trying da patch. Follow status at
https://chromium-status.appspot.com/cq/rpaquay@chromium.org/15738013/85001

[commit-bot: I haz the power, 2013-05-29 02:40:21]

Retried try job too often on win_rel for step(s) browser_tests
http://build.chromium.org/p/tryserver.chromium/buildstatus?builder=win_rel&nu...

[commit-bot: I haz the power, 2013-05-29 15:42:41]

CQ is trying da patch. Follow status at
https://chromium-status.appspot.com/cq/rpaquay@chromium.org/15738013/85001

[commit-bot: I haz the power, 2013-05-29 15:42:47]

Failed to apply patch for
chrome/browser/extensions/extension_function_histogram_value.h:
While running patch -p1 --forward --force --no-backup-if-mismatch;
  patching file chrome/browser/extensions/extension_function_histogram_value.h
  Hunk #1 FAILED at 536.
  1 out of 1 hunk FAILED -- saving rejects to file
chrome/browser/extensions/extension_function_histogram_value.h.rej

Patch:       chrome/browser/extensions/extension_function_histogram_value.h
Index: chrome/browser/extensions/extension_function_histogram_value.h
diff --git a/chrome/browser/extensions/extension_function_histogram_value.h
b/chrome/browser/extensions/extension_function_histogram_value.h
index
e0171e09dad136f3d6d9c651c800f3dc5b08c063..bc8fe6450ee9df3a358d67e700797a7704e10810
100644
--- a/chrome/browser/extensions/extension_function_histogram_value.h
+++ b/chrome/browser/extensions/extension_function_histogram_value.h
@@ -536,6 +536,7 @@ enum HistogramValue {
   FILESYSTEM_ISRESTORABLE,
   FILESYSTEM_RESTOREENTRY,
   RUNTIME_SETUNINSTALLURL,
+  MUSICMANAGERPRIVATE_GETDEVICEID,
   ENUM_BOUNDARY // Last entry: Add new entries above.
 };

[commit-bot: I haz the power, 2013-05-29 16:05:45]

CQ is trying da patch. Follow status at
https://chromium-status.appspot.com/cq/rpaquay@chromium.org/15738013/101001

[commit-bot: I haz the power, 2013-05-29 19:11:03]

Change committed as 202929