summaryrefslogtreecommitdiffstats
path: root/chrome/browser/chrome_process_finder_win.cc
diff options
context:
space:
mode:
authorzturner@chromium.org <zturner@chromium.org@0039d316-1c4b-4281-b951-d872f2087c98>2013-11-07 07:30:52 +0000
committerzturner@chromium.org <zturner@chromium.org@0039d316-1c4b-4281-b951-d872f2087c98>2013-11-07 07:30:52 +0000
commitaec919305de91e5ca2ff11ea78d2bb2461dfa72a (patch)
tree4f612d2e6aeadce5cc4d1c191f4dc163d847054e /chrome/browser/chrome_process_finder_win.cc
parentcfe90f57b4b8375e4dd389410bc715bc00e26a26 (diff)
downloadchromium_src-aec919305de91e5ca2ff11ea78d2bb2461dfa72a.zip
chromium_src-aec919305de91e5ca2ff11ea78d2bb2461dfa72a.tar.gz
chromium_src-aec919305de91e5ca2ff11ea78d2bb2461dfa72a.tar.bz2
Fix some non-aura specific code related to metro startup.
There was a legitimate bug here, but it only occurred on non-aura builds. On aura builds, the code was still incorrect but by luck exhibited the correct behavior. The confusion about this behavior comes from the fact that prior to r232828, we allowed Desktop and Metro instances of chrome to run simultaneously, depending on which shortcut you clicked. As of r232828, all shortcuts lead to the same browser experience, and we store the "stickiness" in the registry and the launch experience is based entirely off of the value stored in the registry. As a result, the code here which was incorrect, and which is fixed in this patch, only matters for non-Aura. BUG=314034 Review URL: https://codereview.chromium.org/60823002 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@233527 0039d316-1c4b-4281-b951-d872f2087c98
Diffstat (limited to 'chrome/browser/chrome_process_finder_win.cc')
-rw-r--r--chrome/browser/chrome_process_finder_win.cc12
1 files changed, 9 insertions, 3 deletions
diff --git a/chrome/browser/chrome_process_finder_win.cc b/chrome/browser/chrome_process_finder_win.cc
index da0f7ae..6959071 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
+ // 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.
+ if (base::win::IsProcessImmersive(process_handle.Get()))
+ chrome::ActivateMetroChrome();
}
+#endif
CommandLine command_line(*CommandLine::ForCurrentProcess());
command_line.AppendSwitchASCII(