Remove supervised users from the app list profile selector.

chrome/browser/ui/app_list/app_list_service_impl.cc

Index: chrome/browser/ui/app_list/app_list_service_impl.cc
diff --git a/chrome/browser/ui/app_list/app_list_service_impl.cc b/chrome/browser/ui/app_list/app_list_service_impl.cc
index 8fcd39861bae6bda488de568acb097862e658bfb..3090c6b9474a0205d8addec03555a8096546724e 100644
--- a/chrome/browser/ui/app_list/app_list_service_impl.cc
+++ b/chrome/browser/ui/app_list/app_list_service_impl.cc
@@ -148,6 +148,13 @@ base::FilePath AppListServiceImpl::GetProfilePath(
 }
 
 void AppListServiceImpl::SetProfilePath(const base::FilePath& profile_path) {
+  // Ensure we don't set the pref to a managed user's profile path.

[koz (OOO until 15th September), 2013/09/25 23:35:58]

Is this ever expected to be hit? If not it should be removed. We don't do other
consistency checks like ensuring that the path exists as it's the caller's
responsibility to ensure such things.

[tapted, 2013/09/26 03:52:50]

Calamity can confirm, but I'm pretty sure this is the path the Settings App goes
through using the button there. There's no filtering for supervised users in
that list, so if someone switches to a supervised user with the settings app, it
will get permanently wedged in a state where it can't show the app list (or
settings again), because of the check in AppListController::ShowForProfile.

This is a slight improvement, although not the best. But the Apps story for
supervised users is broken in a few ways at the moment.

+  ProfileInfoCache& profile_info =
+      g_browser_process->profile_manager()->GetProfileInfoCache();
+  size_t profile_index = profile_info.GetIndexOfProfileWithPath(profile_path);
+  if (profile_info.ProfileIsManagedAtIndex(profile_index))
+    return;
+
   g_browser_process->local_state()->SetString(
       prefs::kAppListProfile,
       profile_path.BaseName().MaybeAsASCII());