Access to Chrome via the System Tray should go through the User Manager.

chrome/browser/ui/views/profiles/user_manager_view.h

 // Copyright 2014 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.
 
 #ifndef CHROME_BROWSER_UI_VIEWS_PROFILES_USER_MANAGER_VIEW_H_
 #define CHROME_BROWSER_UI_VIEWS_PROFILES_USER_MANAGER_VIEW_H_
 
 #include "base/memory/scoped_ptr.h"
 #include "chrome/browser/profiles/profile.h"
 #include "chrome/browser/profiles/profile_window.h"
 #include "ui/views/window/dialog_delegate.h"
 
 class AutoKeepAlive;
 
 namespace views {
 class WebView;
 }
 
 // Dialog widget that contains the Desktop User Manager webui.
 class UserManagerView : public views::DialogDelegateView {
  public:
   // Shows the User Manager or re-activates an existing one, focusing the
   // profile given by |profile_path_to_focus|. Based on the value of
   // |tutorial_mode|, a tutorial could be shown, in which case
-  // |profile_path_to_focus| is ignored.
+  // |profile_path_to_focus| is ignored. After a profile is opened, execute the
+  // |profile_open_action|.
   static void Show(const base::FilePath& profile_path_to_focus,

[Peter Kasting, 2014/09/15 20:17:28]

Nit: I'd eliminate these three public statics and have the UserManager function
implementations in the .cc file just do the necessary bits.  This will require
making more things in UserManagerView public or adding accessors (or,
alternately, declaring UserManager a friend), but it eliminates boilerplate and
avoids the possibility of the UserManager and UserManagerView APIs getting out
of sync.

[Mike Lerman, 2014/09/17 18:31:46]

In the interest of keeping private things private (like instance_) what do you
think of having UserManagerView and UserManagerMac inherit from
c/b/ui/UserManager, and then I can bring the implementations of the *View and
*Mac methods inside the static methods without having to change the visibility
of the private members? You had implied you preferred to avoid explicit
references from UMView and UMMac to the UserManager, but I think this provides a
good reason to create that dependency.

[Peter Kasting, 2014/09/17 20:14:13]

I don't know if I understand your plan.  Perhaps you could partially implement
it (e.g. implement the views side) so I could see what it consists of?

[Mike Lerman, 2014/09/18 18:32:45]

Couldn't find a great approach. I eliminated these three public statics and had
the UserManager implementations do the necessary bits, as you had suggested.

-                   profiles::UserManagerTutorialMode tutorial_mode);
+                   profiles::UserManagerTutorialMode tutorial_mode,
+                   profiles::UserManagerProfileSelected profile_open_action);
 
   // Hide the User Manager.
   static void Hide();
 
   // Returns whether or not the User Manager is showing.
   static bool IsShowing();
 
  private:
   friend struct base::DefaultDeleter<UserManagerView>;
 
@@ skipping 28 matching lines @@
 
   scoped_ptr<AutoKeepAlive> keep_alive_;
   // An open User Manager window. There can only be one open at a time. This
   // is reset to NULL when the window is closed.
   static UserManagerView* instance_;
 
   DISALLOW_COPY_AND_ASSIGN(UserManagerView);
 };
 
 #endif  // CHROME_BROWSER_UI_VIEWS_PROFILES_USER_MANAGER_VIEW_H_