Bug 1468053 - Disable a workaround on macOS 10.14+ for an Apple bug described in bug 378645 involving popup windows that was fixed by Apple. r=mstange, a=IanN CLOSED TREE DONTBUILD SEAMONKEY_2_49_ESR_RELBRANCH
authorStephen A Pohl <spohl.mozilla.bugs@gmail.com>
Thu, 26 Jul 2018 19:01:43 +0300
branchSEAMONKEY_2_49_ESR_RELBRANCH
changeset 357528 c857231c34dffa83b0c5f84aa25d693af1c21f1f
parent 357527 d8da9e2109fc3bf4e312dce3c4901ec34176d007
child 357529 3e238bb605dd4fdedeaef4fb9b07425ebdea705f
push id7834
push userfrgrahl@gmx.net
push dateSun, 13 Jan 2019 12:17:02 +0000
treeherdermozilla-esr52@6e4ad8a8f2e8 [default view] [failures only]
perfherder[talos] [build metrics] [platform microbench] (compared to previous push)
reviewersmstange, IanN
bugs1468053, 378645
milestone52.9.1
Bug 1468053 - Disable a workaround on macOS 10.14+ for an Apple bug described in bug 378645 involving popup windows that was fixed by Apple. r=mstange, a=IanN CLOSED TREE DONTBUILD mozilla-esr52 SEAMONKEY_2_49_ESR_RELBRANCH
widget/cocoa/nsCocoaWindow.mm
--- a/widget/cocoa/nsCocoaWindow.mm
+++ b/widget/cocoa/nsCocoaWindow.mm
@@ -805,25 +805,27 @@ NS_IMETHODIMP nsCocoaWindow::Show(bool b
       else {
         // A sibling of this sheet is active, don't show this sheet yet.
         // When the active sheet hides, its brothers and sisters that have
         // mSheetNeedsShow set will have their opportunities to display.
         mSheetNeedsShow = true;
       }
     }
     else if (mWindowType == eWindowType_popup) {
-      // If a popup window is shown after being hidden, it needs to be "reset"
-      // for it to receive any mouse events aside from mouse-moved events
-      // (because it was removed from the "window cache" when it was hidden
-      // -- see below).  Setting the window number to -1 and then back to its
-      // original value seems to accomplish this.  The idea was "borrowed"
-      // from the Java Embedding Plugin.
-      NSInteger windowNumber = [mWindow windowNumber];
-      [mWindow _setWindowNumber:-1];
-      [mWindow _setWindowNumber:windowNumber];
+      if (!nsCocoaFeatures::OnMojaveOrLater()) {
+        // If a popup window is shown after being hidden, it needs to be "reset"
+        // for it to receive any mouse events aside from mouse-moved events
+        // (because it was removed from the "window cache" when it was hidden
+        // -- see below).  Setting the window number to -1 and then back to its
+        // original value seems to accomplish this.  The idea was "borrowed"
+        // from the Java Embedding Plugin. This is fixed on macOS 10.14+.
+        NSInteger windowNumber = [mWindow windowNumber];
+        [mWindow _setWindowNumber:-1];
+        [mWindow _setWindowNumber:windowNumber];
+      }
       // For reasons that aren't yet clear, calls to [NSWindow orderFront:] or
       // [NSWindow makeKeyAndOrderFront:] can sometimes trigger "Error (1000)
       // creating CGSWindow", which in turn triggers an internal inconsistency
       // NSException.  These errors shouldn't be fatal.  So we need to wrap
       // calls to ...orderFront: in TRY blocks.  See bmo bug 470864.
       NS_OBJC_BEGIN_TRY_ABORT_BLOCK;
       [[mWindow contentView] setNeedsDisplay:YES];
       [mWindow orderFront:nil];
@@ -946,28 +948,32 @@ NS_IMETHODIMP nsCocoaWindow::Show(bool b
     else {
       // If the window is a popup window with a parent window we need to
       // unhook it here before ordering it out. When you order out the child
       // of a window it hides the parent window.
       if (mWindowType == eWindowType_popup && nativeParentWindow)
         [nativeParentWindow removeChildWindow:mWindow];
 
       [mWindow orderOut:nil];
-      // Unless it's explicitly removed from NSApp's "window cache", a popup
-      // window will keep receiving mouse-moved events even after it's been
-      // "ordered out" (instead of the browser window that was underneath it,
-      // until you click on that window).  This is bmo bug 378645, but it's
-      // surely an Apple bug.  The "window cache" is an undocumented subsystem,
-      // all of whose methods are included in the NSWindowCache category of
-      // the NSApplication class (in header files generated using class-dump).
-      // This workaround was "borrowed" from the Java Embedding Plugin (which
-      // uses it for a different purpose).
-      if (mWindowType == eWindowType_popup)
-        [NSApp _removeWindowFromCache:mWindow];
-
+
+      if (!nsCocoaFeatures::OnMojaveOrLater()) {
+        // Unless it's explicitly removed from NSApp's "window cache", a popup
+        // window will keep receiving mouse-moved events even after it's been
+        // "ordered out" (instead of the browser window that was underneath it,
+        // until you click on that window).  This is bmo bug 378645, but it's
+        // surely an Apple bug.  The "window cache" is an undocumented
+        // subsystem, all of whose methods are included in the NSWindowCache
+        // category of the NSApplication class (in header files generated using
+        // class-dump). This workaround was "borrowed" from the Java Embedding
+        // Plugin (which uses it for a different purpose). This is fixed on
+        // macOS 10.14+.
+        if (mWindowType == eWindowType_popup) {
+          [NSApp _removeWindowFromCache:mWindow];
+        }
+      }
       // If our popup window is a non-native context menu, tell the OS (and
       // other programs) that a menu has closed.
       if ([mWindow isKindOfClass:[PopupWindow class]] &&
           [(PopupWindow*) mWindow isContextMenu]) {
         [[NSDistributedNotificationCenter defaultCenter]
           postNotificationName:@"com.apple.HIToolbox.endMenuTrackingNotification"
                         object:@"org.mozilla.gecko.PopupWindow"];
       }