[Fixit-Dec-2012] Auto-launch system-level Chrome post user-level Chrome self-destruction.

chrome/installer/util/util_constants.cc

 // 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.
 
 #include "chrome/installer/util/util_constants.h"
 
 namespace installer {
 
 namespace switches {
 
@@ skipping 136 matching lines @@
 // to support in-use updates. Also deletes opv key.
 const char kRenameChromeExe[] = "rename-chrome-exe";
 
 // Removes Chrome registration from current machine. Requires admin rights.
 const char kRemoveChromeRegistration[] = "remove-chrome-registration";
 
 // When we try to relaunch setup.exe as admin on Vista, we append this command
 // line flag so that we try the launch only once.
 const char kRunAsAdmin[] = "run-as-admin";
 
+// Combined with --uninstall, signals to setup.exe that this uninstall was
+// triggered by a self-destructing Chrome.
+const char kSelfDestruct[] = "self-destruct";

[grt (UTC plus 2), 2013/01/02 17:59:33]

I think this switch should be a little more explicit since it's for the case of
a self-destruct due to the presence of a system-level install. I can imagine
someday there being a need for Chrome to uninstall itself (i.e., to "self
destruct") for other reasons.

Thinking about this at a high level, we have a choice between using switches
that describe the caller's reason for invoking setup (i.e., "Yo setup! Do the
stuff you need to do to handle a user-level self-destruct because there's a new
Chrome in town!") versus using switches that tell setup specifically what the
caller wants it to do (i.e., "Yo setup! Uninstall yourself without prompting the
user, and don't bother removing anything that might be shared with a
system-level Chrome"). The latter seems to be historically what was used in this
case. What are the pros/cons to sticking with the latter? In this case, the new
switch could be something along the lines of "launch-system-chrome-on-success".

[gab, 2013/01/02 21:15:48]

I can imagine more cases where we would want to do something special in setup on
self-destruct then cases where we would want to fine grain call
--launch-system-chrome-on-success et al.

I think adding a new flag for every nit picky thing we want setup to do because
of the same reason is overkill; I prefer saying "Yo Setup! Please uninstall
Chrome, oh and btw this is because user-level Chrome is self-destructing so do
whatever you need to do in this case as well.".

On the other hand I agree that having a flag that does everything can be
dangerous/hard to maintain, but I don't think this is the case, nor will it be
in the near future...

I don't feel like the actual text value of the flag (i.e. --self-destruct versus
--omg-please-do-tha-thang-you-do-on-self-destruct-cause-hey-man-this-is-it-i-just-self-destructed)
matters at all since it's passed as a code constant on one side and read the
same way on the other (this is not the kind of flag we would mention in any sort
of public API...)

+
 // Install Chrome to system wise location. The default is per user install.
 const char kSystemLevel[] = "system-level";
 
 // If present, setup will uninstall chrome.
 const char kUninstall[] = "uninstall";
 
 // Also see --new-setup-exe. This command line option specifies a diff patch
 // that setup.exe will apply to itself and store the resulting binary in the
 // path given by --new-setup-exe.
 const char kUpdateSetupExe[] = "update-setup-exe";
@@ skipping 73 matching lines @@
 // Chrome channel display names.
 const wchar_t kChromeChannelUnknown[] = L"unknown";
 const wchar_t kChromeChannelCanary[] = L"canary";
 const wchar_t kChromeChannelDev[] = L"dev";
 const wchar_t kChromeChannelBeta[] = L"beta";
 const wchar_t kChromeChannelStable[] = L"";
 
 const size_t kMaxAppModelIdLength = 64U;
 
 }  // namespace installer