Fix some non-aura specific code related to metro startup.

chrome/browser/chrome_process_finder_win.cc

Index: chrome/browser/chrome_process_finder_win.cc
diff --git a/chrome/browser/chrome_process_finder_win.cc b/chrome/browser/chrome_process_finder_win.cc
index da0f7aeede3da76ee6c968e0d21df96517a75158..695907130af9399c1350e3e91949cb87b2a38f2f 100644
--- a/chrome/browser/chrome_process_finder_win.cc
+++ b/chrome/browser/chrome_process_finder_win.cc
@@ -112,6 +112,7 @@ NotifyChromeResult AttemptToNotifyRunningChrome(HWND remote_window,
   if (!thread_id || !process_id)
     return NOTIFY_FAILED;
 
+#if !defined(USE_AURA)
   if (base::win::IsMetroProcess()) {
     // Interesting corner case. We are launched as a metro process but we
     // found another chrome running. Since metro enforces single instance then
@@ -140,10 +141,15 @@ NotifyChromeResult AttemptToNotifyRunningChrome(HWND remote_window,
   if (base::win::GetVersion() >= base::win::VERSION_WIN8 &&
       base::OpenProcessHandleWithAccess(
           process_id, PROCESS_QUERY_INFORMATION,
-          process_handle.Receive()) &&
-      base::win::IsProcessImmersive(process_handle.Get())) {
-    chrome::ActivateMetroChrome();
+          process_handle.Receive())) {
+    // Receive() causes the process handle to be set in the destructor of the

[gab, 2013/11/05 22:46:55]

This very much surprised me as I expected the object returned by Receive() to
only live in the scope of base::OpenProcessHandleWithAccess()... so I wrote some
code to verify...

class Foo {
 public:
  Foo() { cout << "constructed foo\n"; }
  ~Foo() {cout << "destructed foo\n"; }
};

bool DoSomethingWithFoo(const Foo& foo) {
  cout << "doing the foo dance\n";
  return true;
}

bool DoSomethingElse() {
  cout << "sad in my bar with no foo\n";
  return true;
}

int _tmain(int argc, wchar_t* argv[])
{
  cout << "warming up\n";
  if (DoSomethingWithFoo(Foo()) &&
      DoSomethingElse()) {
    cout << "done\n";
    return 1;
  }
  return 0;
}

.....

And the output was:
warming up
constructed foo
doing the foo dance
sad in my bar with no foo
destructed foo
done

Showing that the scope of Foo() is indeed the entire if evaluation scope, not
only DoSomethingWithFoo()... very weird... I almost feel this is an MSVC bug...
worth trying on a Linux box with clank if someone has one handy I'd say.

[gab, 2013/11/05 22:50:12]

this ^^^

+    // temporary receiver object, which does not happen until after the if
+    // statement is complete.  So IsProcessImmersive() should only be checked
+    // as part of a separate if statement.

[gab, 2013/11/05 22:46:55]

This is pretty bad... a comment should probably be added to
process_handle.Receive()... even better, this should use a different method as I
don't feel this erroneous usage pattern is uncommon...

+    if (base::win::IsProcessImmersive(process_handle.Get()))
+      chrome::ActivateMetroChrome();

[gab, 2013/11/05 22:46:55]

The use case this was meant to handle is that if you launch chrome.exe from the
command-line (and thus bypass delegate_execute.exe's logic to decide Metro vs
Desktop) we still want to rendez-vous with the Metro Chrome (in singleton mode
we have had no choice...).

Now.. in Aura.. if the only active desktop is Ash; should we activate here
instead of opening a native desktop window? We should do whatever
delegate_execute.exe does in the regular case IMO.

   }
+#endif
 
   CommandLine command_line(*CommandLine::ForCurrentProcess());
   command_line.AppendSwitchASCII(