Fix a bug that caused Chrome OS system preferences not to work in the guest mode.

Fix a bug that caused Chrome OS system preferences not to work in the guest mode. 

Before this change, we were initializing Chrome OS system preferences 
in ProfileImpl's constructor, but this didn't work in the guest mode, 
since we'll switch the profile implementation (GuestSessionProfile) 
afterward in the guest mode.

BUG=chromium-os:11912
TEST=confirm that "Enable tap-to-click" works both in the guest and the normal mode.

Committed: http://src.chromium.org/viewvc/chrome?view=rev&revision=75067

[altimofeev, 2011-02-14 12:33:48]

LGTM, 
but do not forget to run try bots

[satorux1, 2011-02-15 06:35:44]

Ran try bots and found several tests failed. I'm going to rework this patch...

[satorux1, 2011-02-15 10:29:23]

Reworked the patch. Try bots should be happy about this version. :)
Please take another look.

With the original patch, the tests failed as chromeos::Preferences object lived
until the process termination (Singletons are deleted by AtExitManager), hence
outlived PrefService. To solve this problem, we should destroy the object during
the browser shutdown. I originally thought about making the
chromeos::Preferences object as a member variable of some class like Profile, so
the object gets deleted as part of the parent object, but the piggybacking
approach didn't look great as I made a patch locally.

Instead, I added a function with which we can explicitly destroy the
chromeos::Preferences object at the browser shutdown.


On 2011/02/15 06:35:44, satorux1 wrote:
> Ran try bots and found several tests failed. I'm going to rework this patch...

[satorux1, 2011-02-15 12:26:57]

I have a second thought. Since Chrome OS Preferences are associated with a user,
making it part of Profile may make sense. I'll give it another try and see if it
looks better than this.

On 2011/02/15 10:29:23, satorux1 wrote:
> Reworked the patch. Try bots should be happy about this version. :)
> Please take another look.
> 
> With the original patch, the tests failed as chromeos::Preferences object
lived
> until the process termination (Singletons are deleted by AtExitManager), hence
> outlived PrefService. To solve this problem, we should destroy the object
during
> the browser shutdown. I originally thought about making the
> chromeos::Preferences object as a member variable of some class like Profile,
so
> the object gets deleted as part of the parent object, but the piggybacking
> approach didn't look great as I made a patch locally.
> 
> Instead, I added a function with which we can explicitly destroy the
> chromeos::Preferences object at the browser shutdown.
> 
> 
> On 2011/02/15 06:35:44, satorux1 wrote:
> > Ran try bots and found several tests failed. I'm going to rework this
patch...

[altimofeev, 2011-02-15 12:39:00]

I like the idea of leaving Preferences as part of the Profile. Furthermore,
since there could be multiple profiles, in future there could be multiple
preferences.


On 2011/02/15 12:26:57, satorux1 wrote:
> I have a second thought. Since Chrome OS Preferences are associated with a
user,
> making it part of Profile may make sense. I'll give it another try and see if
it
> looks better than this.
> 
> On 2011/02/15 10:29:23, satorux1 wrote:
> > Reworked the patch. Try bots should be happy about this version. :)
> > Please take another look.
> > 
> > With the original patch, the tests failed as chromeos::Preferences object
> lived
> > until the process termination (Singletons are deleted by AtExitManager),
hence
> > outlived PrefService. To solve this problem, we should destroy the object
> during
> > the browser shutdown. I originally thought about making the
> > chromeos::Preferences object as a member variable of some class like
Profile,
> so
> > the object gets deleted as part of the parent object, but the piggybacking
> > approach didn't look great as I made a patch locally.
> > 
> > Instead, I added a function with which we can explicitly destroy the
> > chromeos::Preferences object at the browser shutdown.
> > 
> > 
> > On 2011/02/15 06:35:44, satorux1 wrote:
> > > Ran try bots and found several tests failed. I'm going to rework this
> patch...

[satorux1, 2011-02-15 13:15:26]

Reworked the patch again. Turned out it's simpler than my previous attempts. :)
Please take another look.

[altimofeev, 2011-02-15 13:55:14]

LGTM

On 2011/02/15 13:15:26, satorux1 wrote:
> Reworked the patch again. Turned out it's simpler than my previous attempts.
:)
> Please take another look.