Initialize chrome::DIR_USER_DATA early on for service processes, etc.

chrome/app/chrome_main_delegate.cc

Index: chrome/app/chrome_main_delegate.cc
diff --git a/chrome/app/chrome_main_delegate.cc b/chrome/app/chrome_main_delegate.cc
index 1d79c25c85aa9fd031bbc2c6e1815775e41e3cd0..b03b027981dda92f528a4be39f7646aae420584c 100644
--- a/chrome/app/chrome_main_delegate.cc
+++ b/chrome/app/chrome_main_delegate.cc
@@ -17,6 +17,7 @@
 #include "build/build_config.h"
 #include "chrome/browser/chrome_content_browser_client.h"
 #include "chrome/browser/defaults.h"
+#include "chrome/browser/user_data_dir_extractor.h"
 #include "chrome/common/chrome_constants.h"
 #include "chrome/common/chrome_content_client.h"
 #include "chrome/common/chrome_paths.h"
@@ -33,6 +34,7 @@
 #include "components/startup_metric_utils/startup_metric_utils.h"
 #include "content/public/common/content_client.h"
 #include "content/public/common/content_paths.h"
+#include "content/public/common/main_function_params.h"
 #include "ui/base/ui_base_switches.h"
 
 #if defined(OS_WIN)
@@ -578,6 +580,9 @@ void ChromeMainDelegate::PreSandboxStartup() {
   child_process_logging::Init();
 #endif
 
+  // Initialize chrome::DIR_USER_DATA early on for service processes, etc.
+  chrome::GetUserDataDir(content::MainFunctionParams(command_line));

[Vitaly Buka (NO REVIEWS), 2014/02/20 19:58:17]

Should we fail silently for service or any other child processes?

[msw, 2014/02/20 20:58:48]

Hmm, the dialog does show up a second time when I launch the Chrome Connector
process from Chromium with --user-data-dir="Fake:\Garbage", and worse, it
doesn't create the expected "Service State" file in the actual fallback
DIR_USER_DATA ("C:\Users\msw\AppData\Local\Chromium\User Data\"). Note that
child tab/extension/gpu processes for the browser itself don't fire the dialog
and seem to work okay.

In the next patch set, I fix that issue by appending a --user-data-dir switch
onto the command-line with the fallback directory as needed, so child/service
processes use the expected fallback, rather than re-attempting to use the bad
directory. Thoughts?

+
   stats_counter_timer_.reset(new base::StatsCounterTimer("Chrome.Init"));
   startup_timer_.reset(new base::StatsScope<base::StatsCounterTimer>
                        (*stats_counter_timer_));