Bug 1592416 Comment 46 Edit History

Note: The actual edited comment in the bug view page will always show the original commenter’s name and original timestamp.

I can only reproduce this on macOS 10.15 when the "Assign To" option is used to limit the browser to a particular desktop. This is done by right clicking on the the application's dock icon and using the "Assign To" menu. When the browser is assigned to "None", I could not reproduce the problem. 

In my testing, the two problems this is causing are the right click context menu appears at the wrong location or not at all 1) when the window is not on the assigned desktop and 2) when a window is in full screen mode. 

It seems that after context menu widget is first hidden and nsCocoaWindow::Show() calls [mWindow orderOut:nil], the popup loses its association with the current window and then when it is next unhidden, it displays on the assigned desktop instead of the desktop where the right-click occurred.

Setting the popup window NSWindow collection behavior to NSWindowCollectionBehaviorCanJoinAllSpaces appears to solve this problem and with this change the popup appears in the correct place. When the "Assign To" option is used to assign the browser to a desktop, we still want popups to appear on any desktop that the window is appearing in.  I've tested this so far on 10.11, 10.14, and 10.15 and pre-10.15, the problem was not reproducible and the change appears to have no ill effects.

--

Debugging notes:

Unsuccessfully, I tried various other NSWindow API's to force the popup to appear on the same desktop as the window. Setting the NSWindow.parentWindow property to be the native parent widget was not effective. Using  NSWindow constrainFrameRect:toScreen: to manually set the correct screen was also not effective.

When we create the popup widget by calling nsCocoaWindow::Create(), we provide aParent=null, aNativeParent=<ChildView pointer>, but we don't set mParent although mParent is used (after null checks) in popup code paths. In nsCocoaWindow::Show(), we call `[nativeParentWindow addChildWindow:mWindow ordered:NSWindowAbove]` to add the window back as a child of the native parent, that code is never executed because nativeParentWindow is null. With that code changed to use a valid native parent, that also did not affect the popup location.
I can only reproduce this on macOS 10.15 when the "Assign To" option is used to limit the browser to a particular desktop. This is done by right clicking on the the application's dock icon and using the "Assign To" menu. When the browser is assigned to "None", I could not reproduce the problem. 

In my testing, the two problems this is causing are the right click context menu appears at the wrong location or not at all 1) when the window is not on the assigned desktop and 2) when a window is in full screen mode. 

It seems that after context menu widget is first hidden and nsCocoaWindow::Show() calls [mWindow orderOut:nil], the popup loses its association with the current window and then when it is next unhidden, it displays on the assigned desktop instead of the desktop where the right-click occurred.

Setting the popup window NSWindow collection behavior to NSWindowCollectionBehaviorCanJoinAllSpaces appears to solve this problem and with this change the popup appears in the correct place. When the "Assign To" option is used to assign the browser to a desktop, we still want popups to appear on any desktop that the window is appearing in.  I've tested this so far on 10.11, 10.14, and 10.15 and pre-10.15, the problem was not reproducible and the change appears to have no ill effects.

Edit: NSWindowCollectionBehaviorCanJoinAllSpaces leaves briefly when switching spaces possibly due to being displayed on both spaces at a time and then losing focus and hiding when switching. More work needed.

--

Debugging notes:

Unsuccessfully, I tried various other NSWindow API's to force the popup to appear on the same desktop as the window. Setting the NSWindow.parentWindow property to be the native parent widget was not effective. Using  NSWindow constrainFrameRect:toScreen: to manually set the correct screen was also not effective.

When we create the popup widget by calling nsCocoaWindow::Create(), we provide aParent=null, aNativeParent=<ChildView pointer>, but we don't set mParent although mParent is used (after null checks) in popup code paths. In nsCocoaWindow::Show(), we call `[nativeParentWindow addChildWindow:mWindow ordered:NSWindowAbove]` to add the window back as a child of the native parent, that code is never executed because nativeParentWindow is null. With that code changed to use a valid native parent, that also did not affect the popup location.

Back to Bug 1592416 Comment 46