ChromeOS: switch UI language before apps are loaded.

chrome/browser/profiles/profile.h

Index: chrome/browser/profiles/profile.h
diff --git a/chrome/browser/profiles/profile.h b/chrome/browser/profiles/profile.h
index dcdd6796655934fc433b4d3b19ad7f092ef5ff3c..57dc7306804ca658aa5b2aaf6fb5bb9358e127ff 100644
--- a/chrome/browser/profiles/profile.h
+++ b/chrome/browser/profiles/profile.h
@@ -278,6 +278,13 @@ class Profile : public content::BrowserContext {
 
   // Initializes Chrome OS's preferences.
   virtual void InitChromeOSPreferences() = 0;
+
+  // This hook interrupts initialization flow.

[robliao, 2015/04/13 17:32:30]

It seems what we really want to do is wait for all values to be ready before
actually going down the OnPrefsLoaded path.

If locale should be treated as a pref, can we delay OnPrefsLoaded? All other
components waiting on this pref would benefit.

If locale should not be treated as a pref, can we separate out the relevant
calls in OnPrefsLoaded to something like OnLocaleLoaded? This way it's clear
that we're specifically waiting on locale to get loaded.

[gab, 2015/04/13 17:44:57]

We have the concept of a PrefFilter which can be attached to a JsonPrefStore and
gets first bid before prefs are handed to Chrome (putting this out there, though
I'm not convinced yet that we want this to synchronously block all other prefs).

@Rob: do you think this could be made asynchronous (i.e. it's synchronous today
because extensions are loaded synchronously, could this become one of the async
requirements to begin async load of extensions?)
Agreed that this would be better nomenclature if we take the synchronous route.

[robliao, 2015/04/13 17:49:38]

This could be make asynchronous, but I would rather have a full asynchronous
scheme set before forcing code to do a one-off to handle this.

One more data requirement isn't going hurt things too much on the async front.

[Alexander Alekseev, 2015/04/14 14:20:44]

Hmm. What do you mean?

UI language switch means closing current resource bundle and opening another
language-specific. Component extensions have their manifest stored in resource
bundle, so we need to switch to correct resource bundle before accessing
manifests.

[robliao, 2015/04/14 17:33:20]

I guess the main question here is why does the current resource bundle load
before we load the real language-specific resource bundle?

[Alexander Alekseev, 2015/04/14 18:01:15]

ChromeOS signin UI flow is like this:
1) We usually have several users on a single ChromeOS device. One of
them is considered "device owner".
2) Chrome is started in "login manager" mode. We need to show login UI with user
PODs, network/keyboard menus, "Add new user" UIm etc...
To display all this we are using device owners preferences (actually a copy of
them, because owner profile is encrypted and inaccessible).

3) When user logs in, we check whether current user preferences are the same as
current settings, or not. If not, we apply new settings, including UI language
preference.


So that we need to load some resource bundle to display login UI. But after user
logs in, we probably need to close current resource bundle and load another one.

[robliao, 2015/04/15 22:07:29]

May I suggest this structure then?
The UserSessionManager registers for an OnPrefsLoaded from the prefs.
Once OnPrefsLoaded fires, it does the locale work and fires an OnLocaleReady.

The profile registers for an OnLocaleReady from the UserSessionManager.

The profile only calls the equivalent of OnPrefsLoadedImpl if both OnPrefsLoaded
and OnLocaleReady call back.

+  // It will be called from OnPrefsLoaded() on successful load,
+  // and it must call given closure to proceed profile initialization.
+  // This is needed to switch UI language before apps are initialized.
+  virtual void SetOnPrefsLoadedHook(
+      const base::Callback<void(Profile*, const base::Closure&)>& callback) = 0;
 #endif  // defined(OS_CHROMEOS)
 
   // Returns the helper object that provides the proxy configuration service