Issue #1491 - Part 2: Disable a workaround on macOS 10.14+ for an Apple bug described in Mozilla bug 378645 involving popup windows that was fixed by Apple.

This commit is contained in:
Brian Smith 2020-03-21 17:39:53 -05:00 committed by Roy Tam
commit 186c726563

View file

@ -810,15 +810,17 @@ NS_IMETHODIMP nsCocoaWindow::Show(bool bState)
}
}
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
@ -951,17 +953,22 @@ NS_IMETHODIMP nsCocoaWindow::Show(bool bState)
[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.