Do not load extension system in the Profile import process.

chrome/browser/first_run/first_run_win.cc

Index: chrome/browser/first_run/first_run_win.cc
diff --git a/chrome/browser/first_run/first_run_win.cc b/chrome/browser/first_run/first_run_win.cc
index 8c8707ffbb35ce7dea430be55b96532a040aaf0c..641b131da1626a587751e5415ba15056601da05a 100644
--- a/chrome/browser/first_run/first_run_win.cc
+++ b/chrome/browser/first_run/first_run_win.cc
@@ -332,6 +332,10 @@ bool ImportSettingsWin(Profile* profile,
   };
   import_cmd.CopySwitchesFrom(cmdline, kSwitchNames, arraysize(kSwitchNames));
 
+  // Allow tests to introduce additional switches.
+  import_cmd.AppendArguments(first_run::GetExtraArgumentsForImportProcess(),

[sky, 2012/12/18 16:24:02]

Instead of this, can you mutate the command line after the browser test launches
but before import?

[tapted, 2012/12/19 00:07:53]

I haven't yet found a clean way to do that.. The problem was that if
"--as-browser" is not passed at this point for a test process, then
test_launcher.cc:LaunchTests() tries to restart all the tests, because
--gtest_filter is not included in kSwitchNames just above this line (and I don't
think I can get away with including it ;-). (also, with --gtest_filter, it
crosses the test sharding code paths, which I'm not sure it would like). So
currently only --as-browser is ever appended here (but there's scope for more if
further integration testing is done for the first-run import).

I looked at content::ChildProcessHost::GetChildPath(..CHILD_NORMAL) instead of
cmdline.GetProgram() [line 326 here], but it boils down the same thing, so also
tries to relaunch ./browser_tests from scratch and run all the tests.

Another option would be to include "--import" (and "--import-from-file") in the
list of flags in ShouldRunContentMain(), at
http://code.google.com/searchframe#OAMlx_jo-ck/src/content/public/test/test_l...
But I didn't see a current dependency in test_launcher.cc on
chrome/common/content_switches.h (nor c/b/profiles to get the IsImportProcess
helper I'm introducing).

Creating a duplicate kLaunchAsBrowser[] (.. or "--as-browser" literal) in
first_run_win.cc would also achieve the goal, but might be naughty (and I didn't
think #including test_launcher.h in first_run_win.cc would pass review/DEPS
either). But maybe that's the lesser evil..

Then, I've been poking around more in the test_launcher.cc and browser_tests
code paths, but I'm not seeing a way to hook back into a specific test in order
to mutate the command line, without passing --gtest_filter in the relaunch
command.

[sky, 2012/12/19 16:14:00]

What happens if you add --as-browser to your tests SetUpCommandLine?

+                             false);
+
   // Since ImportSettings is called before the local state is stored on disk
   // we pass the language as an argument.  GetApplicationLocale checks the
   // current command line as fallback.