Add IDL and stub implementation for chrome.usersPrivate API.

chrome/common/extensions/api/users_private.idl

+// Copyright 2015 The Chromium Authors. All rights reserved.
+// Use of this source code is governed by a BSD-style license that can be
+// found in the LICENSE file.
+
+// Use the <code>chrome.usersPrivate</code> API to manage users.
+namespace usersPrivate {
+
+  interface Functions {
+    // Gets a list of the canonicalized emails of the currently whitelisted
+    // users.
+    static void getWhitelistedUsers(DOMString[] emails);

[Dan Beam, 2015/05/23 00:51:14]

why not make this onWhiteListedUsersChanged and fire it immediately when
subscribing?  right now this API has no way to know when a user is
added/removed...

[Oren Blasberg, 2015/05/26 17:04:07]

Implementing that looks pretty challenging if we want to leave the
OwnersSettingsServiceChromeOS alone (which would be preferred).. I see that the
OSSCOS's observe method doesn't provide observers with a way to observe just a
specific path (i.e. the list of whitelisted users), just a generic observe
method [1].

Instead, I suppose we could emulate in C++ what the existing JS implementation
of the user list does, which is to listen on the generic preferences object for
the 'cros.accounts.users' path [2]. In C++ this would mean observing the correct
PrefService for changes, and when the changes affect that path, pass along the
new data to the JS. 

This isn't as simple as it sounds though because the logic for determining which
is the correct PrefService (see "FindServiceForPref" method) is originally in
the CoreOptionsHandler [3] and has since been migrated to the settingsPrivate
API implementation [4]. In the usersPrivate implementation, I could hard code
knowledge about which pref service to use (if indeed it's the same every time)
but I am wary of doing this since if the answer to which pref service to use
ends up changing, we'd have to make the change in two places and not just the
one (settingsPrivate) place.

So.. in the Users page JS, maybe we could just rely on
"chrome.settingsPrivate.onPrefsChanged," filter on 'cros.accounts.users' pref
and in response to that, call the getWhitelistedUsers method to re-populate the
user list. It isn't ideal but maybe a worthwhile tradeoff to make.

I welcome your thoughts on it.

[1]
https://code.google.com/p/chromium/codesearch#chromium/src/chrome/browser/chr...
[2]
https://code.google.com/p/chromium/codesearch#chromium/src/chrome/browser/res...
[3]
https://code.google.com/p/chromium/codesearch#chromium/src/chrome/browser/ui/...
[4]
https://code.google.com/p/chromium/codesearch#chromium/src/chrome/browser/ext...

[Dan Beam, 2015/05/28 20:09:30]

Yeah, this seems fine as long as you're cool with the page knowing this API's
underlying storage is a pref with that name.

[Oren Blasberg, 2015/05/29 23:48:07]

Yep, I'm cool with that. In fact I'm currently adding support for observing
changes to CROS-specific settings in settingsPrivate right now so that will be a
logical mechanism for observing those changes.

Would you mind stamping the CL since you're an owner of the externs file?

+
+    // Adds a new user with the given email to the whitelist.
+    static void addWhitelistedUser(DOMString email);
+
+    // Removes the user with the given email from the whitelist.
+    static void removeWhitelistedUser(DOMString email);
+
+    // Whether the current user is the owner of the device.
+    static void isCurrentUserOwner(boolean isOwner);
+
+    // Whether the whitelist is managed by enterprise.
+    static void isWhitelistManaged(boolean managed);
+  };
+};