Allow Chrome OS login profile to have different default pref values

Allow Chrome OS login profile to have different default pref values

This CL is a prerequisite for putting Chrome in charge of all power
management settings. Since the power management defaults on the login
screen differ from those during a user session, the default values of
the power prefs should be set differently for the login profile.

This CL has no functional changes. It just does the following:

1/ Split chrome::RegisterUserPrefs() into:
 * chrome::RegisterUserProfilePrefs()
 * chrome::RegisterLoginProfilePrefs()

2/ Rename all other RegisterUserPrefs() methods to RegisterProfilePrefs().

BUG=241794
TEST=Updated unit and browser tests

TBR=jochen@chromium.org (blanket rename of RegisterUserPrefs() in chrome/)
TBR=asargent@chromium.org (blanket rename of RegisterUserPrefs() in apps/)
TBR=joi@chromium.org (blanket rename of RegisterUserPrefs() in components/)

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

[bartfab (slow), 2013-06-28 12:17:58]

Hi Mattias,

Could you review the browser_prefs.[cc|h] changes?

All other changes are just updates to consumers of the updated method and can be
TBR'd.

FYI, here are the alternatives I considered:

* Use the same defaults for all profiles. Override the login profile power prefs
with custom values right after creating the profile. This has the disadvantage
that recommended policy no longer works and user-set values cannot be
distinguished from the custom default values initially written to the profile.

* Store power prefs for the login screen in local state, not in the login
profile. This would have the advantage that local state already can have
different default values. The downside is that all power management prefs would
need to be duplicated and the power management code would need to switch between
their local state and per-profile versions. by storing all power prefs in
profiles, only one set of prefs needs to be defined.

[bartfab (slow), 2013-06-28 12:17:58]

Hi Mattias,

Could you review the browser_prefs.[cc|h] changes?

All other changes are just updates to consumers of the updated method and can be
TBR'd.

FYI, here are the alternatives I considered:

* Use the same defaults for all profiles. Override the login profile power prefs
with custom values right after creating the profile. This has the disadvantage
that recommended policy no longer works and user-set values cannot be
distinguished from the custom default values initially written to the profile.

* Store power prefs for the login screen in local state, not in the login
profile. This would have the advantage that local state already can have
different default values. The downside is that all power management prefs would
need to be duplicated and the power management code would need to switch between
their local state and per-profile versions. by storing all power prefs in
profiles, only one set of prefs needs to be defined.

[Mattias Nissler (ping if slow), 2013-07-03 15:18:08]

I think it would be better if you left browser_prefs::RegisterUserPrefs() the
function that everybody can call and add another function
browser_prefs::RegisterLoginProfilePrefs(). The code that's now in
RegisterUserPrefs() could then move to an internal helper named
RegisterProfilePrefs().

Semantically, that's the same as what you have, but more understandable to
somebody who doesn't know what's going on.

[bartfab (slow), 2013-07-03 17:06:34]

On 2013/07/03 15:18:08, Mattias Nissler wrote:
> I think it would be better if you left browser_prefs::RegisterUserPrefs() the
> function that everybody can call and add another function
> browser_prefs::RegisterLoginProfilePrefs(). The code that's now in
> RegisterUserPrefs() could then move to an internal helper named
> RegisterProfilePrefs().
> 
> Semantically, that's the same as what you have, but more understandable to
> somebody who doesn't know what's going on.

Good idea. There are two top-level entry points now:

chrome::RegisterUserProfilePrefs();
chrome::RegisterLoginProfilePrefs();

ProfileImpl() chooses the one to call based on the profile type.

I also renamed the methods that the two entry points above invoke to
RegisterProfilePrefs() throughout the code base as they apply to two different
types of profiles now.

[Mattias Nissler (ping if slow), 2013-07-04 11:41:59]

LGTM

https://codereview.chromium.org/18199003/diff/5002/chrome/browser/sync/sync_p...
File chrome/browser/sync/sync_prefs.cc (left):

https://codereview.chromium.org/18199003/diff/5002/chrome/browser/sync/sync_p...
chrome/browser/sync/sync_prefs.cc:49: // TODO(joi): Remove |prefs| parameter.
Thanks for cleaning this up.

[commit-bot: I haz the power, 2013-07-05 09:33:00]

CQ is trying da patch. Follow status at
https://chromium-status.appspot.com/cq/bartfab@chromium.org/18199003/12001

[commit-bot: I haz the power, 2013-07-05 15:32:52]

Change committed as 210310