Mac: Fix window raising for multiple desktops

ui/base/cocoa/focus_window_set.mm

 // Copyright 2013 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.
 
 #import <Cocoa/Cocoa.h>
 
 #include "ui/base/cocoa/focus_window_set.h"
 
 namespace ui {
 
+// This attempts to match OS X's native behavior, namely that a window
+// is only ever deminiaturized if ALL windows on ALL workspaces are
+// miniaturized. (This callback runs before AppKit picks its own
+// window to deminiaturize, so we get to pick one from the right set.)
+//
+// In addition, limit to the windows on the current
+// workspace. Otherwise we jump spaces haphazardly.
+//
+// NOTE: This is not perfect. If clicking the dock icon resulted in
+// switching spaces, isOnActiveSpace gives the answer for the PREVIOUS
+// space. This means that we actually raise the wrong space's
+// windows. This seems to still work okay.
+//
+// However, if we decide to deminiaturize a window instead, that
+// results in switching spaces and switching back. Fortunately, this
+// only happens if, say, space 1 contains an app, space 2 contains a
+// miniaturized browser. We click the icon, OS X switches to space 1,
+// we deminiaturize the browser, and that triggers switching back.
 void FocusWindowSet(const std::set<NSWindow*>& windows) {
   NSArray* ordered_windows = [NSApp orderedWindows];
   NSWindow* frontmost_window = nil;
   NSWindow* frontmost_miniaturized_window = nil;
+  bool all_miniaturized = true;
   for (int i = [ordered_windows count] - 1; i >= 0; i--) {
     NSWindow* win = [ordered_windows objectAtIndex:i];
     if (windows.find(win) != windows.end()) {
-      if ([win isVisible]) {
-        [win orderFront:nil];
-        frontmost_window = win;
-      } else if ([win isMiniaturized]) {
+      if ([win isMiniaturized]) {
         frontmost_miniaturized_window = win;
+      } else if ([win isVisible]) {
+        all_miniaturized = false;

[jackhou1, 2013/09/02 06:07:23]

Could this be:

      } else if ([win isVisible]) {
        all_miniaturized = false;
        frontmost_window = win;
        if ([win isOnActiveSpace])
          [win orderFront:nil];
      }

[davidben, 2013/09/03 20:01:53]

That seems to cause it to get a bit confused. If frontmost_window wasn't one
that was ordered to front, you end up with key/main windows that aren't on the
current space. It seems to make things go crazy when you press keys.

I can't test the app shim thing, but is the problem that, when the app is on a
different workspace, it doesn't know to switch? What if FocusWindowSet took a
boolean allow_workspace_switch parameter. We track frontmost_window and
frontmost_window_all_spaces. If the former is nil and workspace switch is
allowed, we bring that to front and force a workspace switch. App shims would
pass true because activating the dock icon doesn't allow OS X to use its native
workspace switching behavior. The browser should probably pass false so we still
honor the "[...] switch to a space with open windows for the application"
setting as best we can.

+        if ([win isOnActiveSpace]) {
+          [win orderFront:nil];
+          frontmost_window = win;
+        }
       }
     }
   }
-  if (!frontmost_window && frontmost_miniaturized_window) {
+  if (all_miniaturized && frontmost_miniaturized_window) {
     [frontmost_miniaturized_window deminiaturize:nil];
     frontmost_window = frontmost_miniaturized_window;
   }
   if (frontmost_window) {
     [NSApp activateIgnoringOtherApps:YES];
     [frontmost_window makeMainWindow];
     [frontmost_window makeKeyWindow];
   }
 }
 
 }  // namespace ui