Add fallback behavior if the last used profile cannot initialize

chrome/browser/ui/startup/startup_browser_creator.h

 // Copyright (c) 2012 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_STARTUP_STARTUP_BROWSER_CREATOR_H_
 #define CHROME_BROWSER_UI_STARTUP_STARTUP_BROWSER_CREATOR_H_
 
 #include <string>
 #include <vector>
 
@@ skipping 161 matching lines @@
 
 // Returns true if |profile| has exited uncleanly and has not been launched
 // after the unclean exit.
 bool HasPendingUncleanExit(Profile* profile);
 
 // Returns the path that contains the profile that should be loaded on process
 // startup.
 base::FilePath GetStartupProfilePath(const base::FilePath& user_data_dir,
                                      const base::CommandLine& command_line);
 
+#if !defined(OS_CHROMEOS) && !defined(OS_ANDROID)
+// Returns the profile that should be loaded on process startup. This is either
+// the profile return by GetStartupProfilePath, or the guest profile if the

[Peter Kasting, 2016/07/01 00:53:23]

Nit: returned

[WC Leung, 2016/07/07 17:01:54]

Done.

+// above profile is locked. The guest profile denotes that we should open the
+// user manager. Returns null if the above profile cannot be opened. In case of

[Peter Kasting, 2016/07/01 00:53:23]

Why does returning the guest profile denote opening the user manager?  Why not
return some sort of code or boolean indicating whether to show the user manager?
 Or do we have to use the guest profile behind the scenes while the user manager
is visible (and if so why)?

[WC Leung, 2016/07/07 17:01:54]

I suggest a structure with an enum and a Profile*. BTW, let's start a separate
issue for this. I need to grok the different callsites before making a CL that
does not break things.
No. That's why it's very strange. And the Mac code seems NOT to follow this
tradition of returning the guest profile at all. (I'm not 100% sure about this
though.)

[Peter Kasting, 2016/07/11 02:58:59]

Hmm.  Sounds like this does need cleanup, and you'd rather do it in another CL,
which I'm OK with.

+// user manager, returns null if either the guest profile and the system profile

[Peter Kasting, 2016/07/01 00:53:24]

Nit: Do you mean "neither/nor...can be opened"?  How does the "system profile"
(what is that) factor into everything?

[WC Leung, 2016/07/07 17:01:54]

I do really mean "either".

If the guest profile cannot be opened we have nothing to return (until we solved
the issue above). If if the system profile cannot be opened we cannot load the
user manager.

BTW, I'd rather not to explain about the system profile at this stage, because
the most confusing part is the guest profile. (And you're commented in several
places about the guest profile.) When/if the issue above is finally solved, then
we don't need to explain at all.

[Peter Kasting, 2016/07/11 02:58:59]

Then I think you meant to use "either...or" instead of "either...and".

[WC Leung, 2016/07/18 17:56:18]

Done. Sorry for this stupid mistake.

+// cannot be opened.
+Profile* GetStartupProfile(const base::FilePath& user_data_dir,
+                           const base::CommandLine& command_line);
+
+// Returns the a fallback profile that should be loaded on process startup.

[Peter Kasting, 2016/07/01 00:53:24]

Nit: extra a

Explain what a fallback profile is.

[WC Leung, 2016/07/07 17:01:54]

Done.

+// Possible to return null, which means no profile (including user manager) can

[Peter Kasting, 2016/07/01 00:53:24]

The user manager isn't a profile, so this sentence is a bit confusing.

[WC Leung, 2016/07/07 17:01:54]

Revised the comment. PTAL.

+// be opened.
+Profile* GetFallbackStartupProfile();
+#endif  // !defined(OS_CHROMEOS) && !defined(OS_ANDROID)
+
 #endif  // CHROME_BROWSER_UI_STARTUP_STARTUP_BROWSER_CREATOR_H_