diff options
author | gab@chromium.org <gab@chromium.org@0039d316-1c4b-4281-b951-d872f2087c98> | 2013-08-08 22:20:00 +0000 |
---|---|---|
committer | gab@chromium.org <gab@chromium.org@0039d316-1c4b-4281-b951-d872f2087c98> | 2013-08-08 22:20:00 +0000 |
commit | 0a160a1b87044b0c795eed63f9be8d13a953a9be (patch) | |
tree | 4c8da0391797ddcf571886a2a159658f9ebfcb8d /chrome/test | |
parent | 23bc585c9f12b330eb44442e5b4057d0ee9941fd (diff) | |
download | chromium_src-0a160a1b87044b0c795eed63f9be8d13a953a9be.zip chromium_src-0a160a1b87044b0c795eed63f9be8d13a953a9be.tar.gz chromium_src-0a160a1b87044b0c795eed63f9be8d13a953a9be.tar.bz2 |
Introduce --cancel-first-run and reduce the strength of --no-first-run.
--cancel-first-run has the same behavior as the old --no-first-run in that it writes the First Run sentinel (to prevent any later launch from being considered first run) on top of preventing the current run from being considered first run.
In most situations this is too strong and the consumer actually only wants to prevent the current run from being first run; while still allowing a future launch of chrome to be the first run.
This changes the behavior of Chrome Frame which now doesn't write the First Run sentinel (and thus allows a subsequent run of the real Chrome to be first run).
The only case where --cancel-first-run is actually needed is when a user-level Chrome which has already gone through first run self-destructs upon finding a system-level Chrome install on the same machine. After uninstalling itself, it launches system-level Chrome and needs --cancel-first-run to tell it that it should not do first run and just load the current user's prefs straight up (essentially resulting in the same thing as a regular launch of the user-level Chrome from the user's pov).
This is a follow-up on the discussion @ https://codereview.chromium.org/20483002/diff/10002/chrome/browser/first_run/first_run.cc#newcode492 and
https://codereview.chromium.org/20483002/diff/10002/chrome/browser/chrome_browser_main.cc#oldcode988
Note that InProcessBrowserTest already adds --no-first-run to all tests, so respecifying the flag in sub-test-fixtures is superfluous and such code was removed in this CL as well.
To make sure that no instance of --no-first-run was ignored, patch set 10 actually replaces all instances of --no-first-run by --skip-first-run. It was however deemed too complex (https://codereview.chromium.org/21150006/diff/41001/chrome/common/chrome_switches.cc#oldcode968) to fully replace the flag since many tools outside of Chrome's codebase use --no-first-run and updating all of them to --skip-first-run just to keep the current behavior seemed like overkill. Patch set 11 thus reverted all --skip-first-run flags to --no-first-run.
BUG=265549
Review URL: https://chromiumcodereview.appspot.com/21150006
git-svn-id: svn://svn.chromium.org/chrome/trunk/src@216460 0039d316-1c4b-4281-b951-d872f2087c98
Diffstat (limited to 'chrome/test')
-rw-r--r-- | chrome/test/nacl/nacl_browsertest_util.cc | 1 |
1 files changed, 0 insertions, 1 deletions
diff --git a/chrome/test/nacl/nacl_browsertest_util.cc b/chrome/test/nacl/nacl_browsertest_util.cc index c1e5655..266a5d7 100644 --- a/chrome/test/nacl/nacl_browsertest_util.cc +++ b/chrome/test/nacl/nacl_browsertest_util.cc @@ -203,7 +203,6 @@ NaClBrowserTestBase::~NaClBrowserTestBase() { } void NaClBrowserTestBase::SetUpCommandLine(CommandLine* command_line) { - command_line->AppendSwitch(switches::kNoFirstRun); command_line->AppendSwitch(switches::kEnableNaCl); } |