1592416 - Right click opens context menu on wrong monitor or virtual desktop (mac OS Catalina)

Status: VERIFIED FIXED

(Core :: Widget: Cocoa, defect, P1)

Description

[yoachim]

Attachment: sc2.png

User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:70.0) Gecko/20100101 Firefox/70.0

Steps to reproduce:

Opened a few firefox windows, dragged one from desktop 1 to desktop 5 (second monitor). clicked on folders in my toolbar folder, right clicked on images to download them.

Actual results:

Things show up in the proper place on first click, but after that only show up on Desktop 1.

Expected results:

I expect menus to stay on the same desktop as the browser. Tried turning off hardware acceleration and that didn't help. Here's a screenshot showing a right-click popup menu off floating in space on the wrong desktop.

Comment 1

[:Gijs (he/him)]

:spohl, we're getting the context menu right click event and passing its screenX and screenY coordinates to popup.openPopupAtScreen. Any idea why that would break in this way?

Reporter: what's the screen configuration between the 2 desktops (ie what resolution are they, are they both hi/lo DPI, etc.) and did you attach/detach the second monitor while Firefox was running? Does the problem persist after restarting Firefox?

Comment 2

[yoachim]

Reporter: what's the screen configuration between the 2 desktops (ie what resolution are they, are they both hi/lo DPI, etc.) and did you attach/detach the second monitor while Firefox was running? Does the problem persist after restarting Firefox?

Monitor 1 is 2560x1440, monitor 2 is 1920x1200, both their defaults. No attaching/detaching. Tried restarting firefox and rebooting, doesn't clear up issue.

Looks like the issue is present even if I have only one monitor. If a firefox window starts on desktop 1, everything is fine. If I then drag it to desktop 2, right-click pop up window doesn't appear (but I can find it back on desktop 1). Folders in the bookmark toolbar will open once, then subsequent clicks make them open back on desktop 1. Things started behaving badly when I updated to Catalina, then got worse with 10.15.1.

Comment 3

[:Gijs (he/him)]

This seems like a problem with how cocoa manages virtual desktops, then...

Comment 4

[yoachim]

It's only firefox that has the issue, all my other apps can go between desktops and display popups in the proper place.

Comment 6

[Stephen A Pohl [:spohl]]

Did this happen in older versions of Firefox? If not sure, could you run mozregression[1] to see when this started happening? If you have never run mozregression before, simply run these three commands in a Terminal window:

sudo easy_install pip
sudo pip2 install -U mozregression --ignore-installed
mozregression

A number of Firefox versions will open in succession to narrow down when this started occurring. Simply type "good" or "bad" in Terminal based on whether or not a build reproduces the bug. Once finished, please post the output from the last run. It should give a last good and first bad revision as well as a link to look at the changesets in that range. Thank you!

[1] https://mozilla.github.io/mozregression/

Comment 7

[yoachim]

Attachment: mozregression traceback

(In reply to Stephen A Pohl [:spohl] from comment #6)

mozregression dies with:

Comment 8

[yoachim]

(In reply to Stephen A Pohl [:spohl] from comment #6)

mozregression dies with:

Comment 9

[Stephen A Pohl [:spohl]]

Dirk, would you be able to try if mozregression works for you? See comment 6. Thank you!

Comment 10

[:Gijs (he/him)]

(In reply to yoachim from comment #8)

(In reply to Stephen A Pohl [:spohl] from comment #6)

mozregression dies with:

Assuming all this worked at some point, you could try something like mozregression --good 2015-01-01 (or perhaps even later? Unsure when we stopped doing universal builds) to avoid hitting old binaries which 10.15 is refusing to run. It'll run the "bounds" builds first, so if 2015-01-01 is also broken (either in the sense that the bug reproduces, or in the sense that it's refusing to run, too) you will find out quicly...

Comment 11

[yoachim]

OK, mozregression --good 2017-01-01 runs and both the browsers it popped open ran fine:
1:38.98 ERROR: Build was expected to be bad! The initial good/bad range seems incorrect.

I just grabbed Firefox Nightly and confirmed the bug doesn't show up there.

Comment 12

[:Gijs (he/him)]

(In reply to yoachim from comment #11)

OK, mozregression --good 2017-01-01 runs and both the browsers it popped open ran fine:
1:38.98 ERROR: Build was expected to be bad! The initial good/bad range seems incorrect.

I just grabbed Firefox Nightly and confirmed the bug doesn't show up there.

This is very surprising. There are more or less 2 possibilities:

1. there's something specific about your profile that is tripping this
2. this broke between 2017-01-01 and 70, and then got fixed.

We can exclude the first if you:

1. open your regular Firefox copy
2. go to about:profiles
3. click 'create a new profile', name it, and load that profile in a new browser

and see if the issue reproduces that way.

If it doesn't reproduce that way, can you please go to about:support in the profile that's broken, click 'copy raw data to clipboard' and paste at https://bugzilla.mozilla.org/attachment.cgi?bugid=1592416&action=enter to attach to this bug? Hopefully we can deduce from that what might be different and therefore tripping this problem.

If it does reproduce then, you could try again with mozregression --find-fix --bad 70 to see if we can figure out what fixed this, which we may be able to use to uplift a fix to 71 so it reaches release channel sooner...

Thank you for helping us figure this out!

Comment 13

[yoachim]

If it does reproduce then, you could try again with mozregression --find-fix --bad 70 to see if we can figure out what fixed this, which we may be able to use to uplift a fix to 71 so it reaches release channel sooner...

New profile does still have the bug. mozregression --find-fix --bad 70 doesn't pop open any buggy browsers.

Comment 14

[:Gijs (he/him)]

(In reply to yoachim from comment #13)

If it does reproduce then, you could try again with mozregression --find-fix --bad 70 to see if we can figure out what fixed this, which we may be able to use to uplift a fix to 71 so it reaches release channel sooner...

New profile does still have the bug. mozregression --find-fix --bad 70 doesn't pop open any buggy browsers.

OK, I'm out of ideas as to what could explain the difference, except maybe settings that are different on Firefox Nightly vs. release. But I don't know of any such settings that would have this kind of impact - though I'm not familiar with our cocoa code, so maybe :spohl has more ideas given all this info...

Comment 15

[Stephen A Pohl [:spohl]]

No, I wouldn't know of any such difference... It would be good to hear if Dirk is also unable to reproduce in current Nightly.

Comment 17

[Bruce A. Locke]

Attachment: Screen Recording 2019-11-12 at 12.20.50 PM.mov

Video of primary screen while attempting to bring up right click menu on second screen

Comment 18

[Bruce A. Locke]

This affects me on Firefox 70.0.1 running on Catalina 10.15.1 on a Macbook Pro (13 inch, 2016). Issue begins on the second attempt to right click on a window on the second screen.

Primary display is an external 1920x1080, Second display is the internal display is Macbook display at 2560x1600. Screen arrangement is laptop internal higher res screen on the "left" and the external display with lower screen resolution on the right. Primary screen is the lower resolution external screen on the right.

Video demonstrates me right clicking on a Firefox window on the "left" internal display and the menu appearing on the "right" external display. It also demonstrates Firefox getting confused about window scaling which is a separate issue.

I was unable to reproduce on today's nightly build so this might be fixed.

Comment 19

[BugBot [:suhaib / :marco/ :calixte]]

Bugbug thinks this bug is a regression, but please revert this change in case of error.

Comment 20

[:Gijs (he/him)]

(In reply to Bruce A. Locke from comment #18)

I was unable to reproduce on today's nightly build so this might be fixed.

I think the confusing thing is that people also cannot reproduce on older nightly builds, so there's no guarantee that once the code in today's nightly hits release, release is actually fixed. :-\

Comment 25

[Francesco Lodolo [:flod]]

I assume this is the bug I'm seeing with Nightly and a display connected via AirPlay (originally reported as bug 1610187).

Nightly: 74.0a1 (2020-01-18) (64 bit)
OS: Catalina (10.15.2 (19C57))

The same Nightly was working correctly with 10.14

Comment 26

[Francesco Lodolo [:flod]]

Additional note: if I open a new window, and drag it to the AirPlay display, the first time a context menu is displayed correctly. From the second time, it's always displayed on the wrong display and "out of scale" (text is smaller than necessary, empty space).

Comment 33

[max]

still experiencing this on the latest beta releases - 74.0b4 (64-bit)
Catalina 10.15.2

Comment 34

[Marko Ramius]

Experiencing this issue, too. FF 73.0.1 on Mac OS 10.15.3.
Not only the context menu appears on the wrong screen but also search suggestions, stored password dropdowns.
Besides this, having Firefox in full screen mode on the laptop (13'' MB Pro) renders those menus much too large on the external display.

Comment 35

[lucavgobbi]

The issue only happens to me if I assign firefox to one desktop (Right click > Options > Assign to ...)

When "None" is selected the context menu appears whenever the window is. This is probably why most people can't reproduce on Nightly builds, since they are not assigned to any desktops.

Firefox 73.0.1 (64-bit)

Comment 36

[Karl W.]

(In reply to lucavgobbi from comment #35)

The issue only happens to me if I assign firefox to one desktop (Right click > Options > Assign to ...)

When "None" is selected the context menu appears whenever the window is. This is probably why most people can't reproduce on Nightly builds, since they are not assigned to any desktops.

Firefox 73.0.1 (64-bit)

Using nightly worked for me for a couple of weeks until seemingly suddenly, I got the issue again.

I can however confirm that manually assigning the window to any desktop (all, a specific one or none) solves the issue, at least for now!

Comment 37

[Tom]

(In reply to Karl W. from comment #36)

(In reply to lucavgobbi from comment #35)

The issue only happens to me if I assign firefox to one desktop (Right click > Options > Assign to ...)

When "None" is selected the context menu appears whenever the window is. This is probably why most people can't reproduce on Nightly builds, since they are not assigned to any desktops.

Firefox 73.0.1 (64-bit)

Using nightly worked for me for a couple of weeks until seemingly suddenly, I got the issue again.

I can however confirm that manually assigning the window to any desktop (all, a specific one or none) solves the issue, at least for now!

I second this, I'm on Firefox 75.0b2 (64-bit) and having the same problem. Above method fixes it, but only temporarily.

Comment 39

[:Gijs (he/him)]

The most recent dupe points out that this affects shortcut keypresses, too - closing the tab/window with cmd-w doesn't work, for instance.

:haik, can you see if we can find an owner for this? This is one of the most-duped bugs that have been filed since the Catalina release (in general, not just in relation to Catalina).

Comment 40

[Haik Aftandilian [:haik]]

Still looking into this. I tried a mozregression and the oldest build I tried was 2016-08-01 and I could reproduce the problem where a right click on one virtual desktop ends up displaying a popup in another desktop. I'm testing on macOS 10.15.

Comment 41

[Haik Aftandilian [:haik]]

When hitting this on a debug build, I see this warning from ~WidgetMouseEvent():

[Parent 35847, Main Thread] WARNING: Wrong button set to eContextMenu event?:
'mMessage != eContextMenu || mButton == ((mContextMenuTrigger == eNormal) ? MouseButton::eRight : MouseButton::eLeft)',
file /Users/haftandilian/r/mc/obj-dbg.noindex/dist/include/mozilla/MouseEvents.h, line 238

Comment 42

[Haik Aftandilian [:haik]]

I don't understand all the code involved, but in my testing so far, I can't reproduce the problem with this change.

 void nsMenuPopupFrame::InitializePopupAtScreen(nsIContent* aTriggerContent,
                                                int32_t aXPos, int32_t aYPos,
                                                bool aIsContextMenu) {
-  EnsureWidget();
+  EnsureWidget(true);

Like what :flod observed on comment 26, the first time I right-click on the window that is on another virtual desktop, it is displayed correctly, then on subsequent right-clicks, it is displayed on the wrong desktop. So I looked for things being cached when a popup is displayed. Still debugging.

Comment 43

[Haik Aftandilian [:haik]]

(In reply to Haik Aftandilian [:haik] from comment #42)

I don't understand all the code involved, but in my testing so far, I can't reproduce the problem with this change.

 void nsMenuPopupFrame::InitializePopupAtScreen(nsIContent* aTriggerContent,
                                                int32_t aXPos, int32_t aYPos,
                                                bool aIsContextMenu) {
-  EnsureWidget();
+  EnsureWidget(true);

Like what :flod observed on comment 26, the first time I right-click on the window that is on another virtual desktop, it is displayed correctly, then on subsequent right-clicks, it is displayed on the wrong desktop. So I looked for things being cached when a popup is displayed. Still debugging.

:spohl, :mstange, any ideas on why recreating the widget each time we display a popup menu would solve this problem? Without the above change, the first right-click works, but subsequent right-clicks on a window show the popup on the wrong desktop (if the window is not in the assigned desktop.) Where assigned desktop refers to right-click on the dock icon Options->Assign To desktop.

Comment 44

[Stephen A Pohl [:spohl]]

(In reply to Haik Aftandilian [:haik] from comment #43)

:spohl, :mstange, any ideas on why recreating the widget each time we display a popup menu would solve this problem? Without the above change, the first right-click works, but subsequent right-clicks on a window show the popup on the wrong desktop (if the window is not in the assigned desktop.) Where assigned desktop refers to right-click on the dock icon Options->Assign To desktop.

It would be interesting to log/track any changes to the widget between two consecutive openings of the popup. Presumably, we create the widget correctly the first time the popup is opened. Could it be that when we hide the popup[1], the widget changes in such a way that we can no longer rely on it to display the popup in the correct place? Is it getting detached from its parent for example? I would probably debug/log there next.

[1] https://searchfox.org/mozilla-central/source/layout/xul/nsXULPopupManager.cpp#865

Comment 45

[Haik Aftandilian [:haik]]

(In reply to Stephen A Pohl [:spohl] from comment #44)

It would be interesting to log/track any changes to the widget between two consecutive openings of the popup. Presumably, we create the widget correctly the first time the popup is opened. Could it be that when we hide the popup[1], the widget changes in such a way that we can no longer rely on it to display the popup in the correct place? Is it getting detached from its parent for example? I would probably debug/log there next.

[1] https://searchfox.org/mozilla-central/source/layout/xul/nsXULPopupManager.cpp#865

Thanks, I'm still trying to find what is different. Losing attachment to the parent window seems like it would explain the problem. In nsCocoaWindow::Show() we call [mWindow orderOut:nil] which is documented to remove the window from its parent window. But when I check the value of [mWindow parentWindow], it's always null including for the working case.

Comment 46

[Haik Aftandilian [:haik]]

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.

Comment 47

[Haik Aftandilian [:haik]]

My current approach with this is to use NSWindowCollectionBehaviorMoveToActiveSpace to solve the problem where Firefox is assigned to a particular space. This doesn't address the problem where Firefox is assigned to a particular space and multiple displays are present. For the multi-display case, the changes I'm working on recreate the widget to work around the problem.

This also occurs for dialogs like Print, Page Setup, and Save As. Print and Page Setup don't inherit from NSWindow and there does not appear to be an API to get NSWindowCollectionBehaviorMoveToActiveSpace behavior for them. For dialogs like Save As that do inherit from NSWindow, we could apply the same fix, but the result would be inconsistent behavior for different dialogs. Since the system behavior for dialogs like Print is to display on the "Assign To" space, matching that behavior seems acceptable for these windows.

Safari also exhibits this problem for some dialogs such as File->Open (with multi-screen, multi-space, and "Assign To" enabled). Other Safari dialogs are implemented as NSSheet and are anchored to the window regardless of screen or space with "Assign To".

Comment 48

[Haik Aftandilian [:haik]]

Attachment: Bug 1592416 - Right click opens context menu on wrong monitor or virtual desktop (mac OS Catalina) r?spohl

Add the NSWindowCollectionBehaviorMoveToActiveSpace behavior to nsCocoaWindow
popups so that they override the "Assign To" space setting and display on the
active space.

With mutiple displays, recreate the popup widget each time it is displayed
to workaround a problem where the re-shown popup appears on the "Assign To"
display instead of the current display.

Comment 53

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/09ccf334001b
Right click opens context menu on wrong monitor or virtual desktop (mac OS Catalina) r=spohl

Comment 54

[Bogdan Tara[:bogdan_tara | bogdant]]

https://hg.mozilla.org/mozilla-central/rev/09ccf334001b

Comment 55

[Haik Aftandilian [:haik]]

I've requested the fix be backed out from central for causing 1640077.

Comment 56

[Marko Ramius]

Thank you so much for fixing this. This behaviour is/was extremely annoying.

I immediately downloaded todays nightly build and had a look at the fix. It works fine if I maximize (green button) Firefox on my secondary (laptop) display and open context menus. Even if I open the same context menu multiple times, it appears in the correct position.
Just one thing I noticed: When the context menu opens, it shortly shows a much too big grey background. The menu background does resize to the correct size very quickly (probably when I release the right mouse button, but I can't reproduce it reliably). Obviously this is by far less disturbing as the original bug, but it looks a bit bumpy.

I have a MacBook Pro (Retina, 13", End 2013) with an extrenal display attached, running Mac OS 10.15.4 (19E287).

Comment 57

[Pulsebot]

Backout by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/17e9d170ba1b
Backed out changeset 09ccf334001b for causing bug 1640077 to fail.

Comment 58

[Pulsebot]

Backout by [e-mail]:
https://hg.mozilla.org/mozilla-central/rev/fbf71e4d2e21
Backed out changeset 09ccf334001b for causing bug 1640077 to fail.

Comment 59

[Haik Aftandilian [:haik]]

Attachment: Bug 1592416 - Right click opens context menu on wrong monitor or virtual desktop (mac OS Catalina) r?spohl

Add the NSWindowCollectionBehaviorMoveToActiveSpace behavior to nsCocoaWindow
popups so that they override the "Assign To" space setting and display on the
active space.

This also addresses bug 1589893 where, when "Assign To" space is used, popup
menus are not visible in full screen mode.

With mutiple displays, recreate the popup widget each time it is displayed
to workaround a problem where the re-shown popup appears on the "Assign To"
display instead of the current display.

Comment 60

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/854feb05fff6
Right click opens context menu on wrong monitor or virtual desktop (mac OS Catalina) r=spohl

Comment 61

[Razvan Maries]

Backed out for perma failures.

Push with failure: https://treeherder.mozilla.org/#/jobs?repo=autoland&resultStatus=pending%2Crunning%2Csuccess%2Ctestfailed%2Cbusted%2Cexception&searchStr=os%2Cx%2C10.14%2Cdebug%2Cmochitests%2Ctest-macosx1014-64%2Fdebug-mochitest-browser-chrome-e10s-3%2Cm%28bc3%29&revision=0b74b615f7ad056f326e9e2147b21d18bc4bb89e&selectedTaskRun=DKY-vSw4RhOSkW9pCkIRcw-0

Failure log: https://treeherder.mozilla.org/logviewer.html#/jobs?job_id=304025816&repo=autoland&lineNumber=2493

Backout: https://hg.mozilla.org/integration/autoland/rev/fcd578c812db156400ba68cfeb86d3d6474524bd

Comment 62

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/d7f46110bc8b
Right click opens context menu on wrong monitor or virtual desktop (mac OS Catalina) r=spohl

Comment 63

[Noemi Erli[:noemi_erli]]

https://hg.mozilla.org/mozilla-central/rev/d7f46110bc8b

Comment 64

[Haik Aftandilian [:haik]]

(In reply to Marko Ramius from comment #56)

Thank you so much for fixing this. This behaviour is/was extremely annoying.

I immediately downloaded todays nightly build and had a look at the fix. It works fine if I maximize (green button) Firefox on my secondary (laptop) display and open context menus. Even if I open the same context menu multiple times, it appears in the correct position.
Just one thing I noticed: When the context menu opens, it shortly shows a much too big grey background. The menu background does resize to the correct size very quickly (probably when I release the right mouse button, but I can't reproduce it reliably). Obviously this is by far less disturbing as the original bug, but it looks a bit bumpy.

I have a MacBook Pro (Retina, 13", End 2013) with an extrenal display attached, running Mac OS 10.15.4 (19E287).

Thanks for testing it out, Marko. The fix was backed out from Nightly and now has been reintegrated, but not quiet available in the Nightly channel yet. If the extra large gray background is still reproducible once you have the fix, please file a new bug or let us know.

Comment 66

[Haik Aftandilian [:haik]]

Adding qe-verify flag to request additional QE verification of this fix. We want to make sure that popup menus including right click popup menus and toolbar popup menus work correctly on recent Mac OS versions with different combinations of the following: 1) multiple screens are enabled 2) multiple workspaces enabled 3) having Firefox assigned to a particular display with "Dock icon -> Options -> Assign To" 4) Firefox is in full screen mode.

Comment 67

[Marko Ramius]

(In reply to Haik Aftandilian [:haik] from comment #64)
...

Thanks for testing it out, Marko. The fix was backed out from Nightly and now has been reintegrated, but not quiet available in the Nightly channel yet. If the extra large gray background is still reproducible once you have the fix, please file a new bug or let us know.

I am now on 78.0b3. The large grey background still appears here, but to me it seems faster than with the nightly. It is just a real quick flicker when the context menu opens; after that, the context menus resize correctly. This does not only happen on first or second opening of a context menu, but stays reproducible after dozens of clicks.

This is just an addon, but my RSS-Feeds with Livemarks (v. 2.8) still opening on the wrong screen. Probably the API used here to display the Live Bookmarks is still broken.

Comment 68

[Marko Ramius]

(In reply to Marko Ramius from comment #67)

(In reply to Haik Aftandilian [:haik] from comment #64)
...
I would like to leave it open to you whether to open a new bug or not. Obviously the main problem is solved and that is the most important thing for users like me. Thanks again.

Comment 69

[Marko Ramius]

(In reply to Marko Ramius from comment #68)

(In reply to Marko Ramius from comment #67)

(In reply to Haik Aftandilian [:haik] from comment #64)
...
I found another defect: Stored password and credential dropdowns still appear on the wrong monitor (I have Firefox on my MacBookPro's display, log into e.g. Twitter, and my account name dropdown appears in too large letters on my main display connected via HDMI. I assume the too large letters occur due to the higher pixel density of the Retina display compared to the standard LCD display.

Comment 70

[:Gijs (he/him)]

(In reply to Marko Ramius from comment #69)

I found another defect: Stored password and credential dropdowns still appear on the wrong monitor (I have Firefox on my MacBookPro's display, log into e.g. Twitter, and my account name dropdown appears in too large letters on my main display connected via HDMI. I assume the too large letters occur due to the higher pixel density of the Retina display compared to the standard LCD display.

Please can you file a separate follow-up bug? Thanks.

Comment 71

[Marko Ramius]

(In reply to :Gijs (he/him) from comment #70)
...

Please can you file a separate follow-up bug? Thanks.
Thanks for your feedback. That is now done: https://bugzilla.mozilla.org/show_bug.cgi?id=1644109

Comment 73

[Catalin Sasca, Desktop Test Engineering [:csasca]]

I successfully reproduced the issue on Firefox Nightly 72.0a1 (2019-10-29) under macOS 10.15.5 using the STR from Comment 0 and some help from haik.

The issue is fixed on Firefox 78.0b8 and Nightly 79.0a1 (2020-06-17).

Comment 74

[Tyler.Exposure]

(In reply to Catalin Sasca, QA [:csasca] from comment #73)

I successfully reproduced the issue on Firefox Nightly 72.0a1 (2019-10-29) under macOS 10.15.5 using the STR from Comment 0 and some help from haik.

The issue is fixed on Firefox 78.0b8 and Nightly 79.0a1 (2020-06-17).

I'm running firefox beta on mac, I just updated to FF beta 78.0 from 78.0b8 and I am still having the same issue.

When you first open the browser and right-click, the context sub-menus come up correctly, but after the first time, the context-sub menus appear on my laptop monitor and not my 2nd monitor. The actual right-click context menu shows up fine, it is only the sub-context menus now, primarily when I go to close all the tabs to the right, that menu is on my first monitor.

Comment 75

[Haik Aftandilian [:haik]]

(In reply to Tyler.Exposure from comment #74)

I'm running firefox beta on mac, I just updated to FF beta 78.0 from 78.0b8 and I am still having the same issue.

When you first open the browser and right-click, the context sub-menus come up correctly, but after the first time, the context-sub menus appear on my laptop monitor and not my 2nd monitor. The actual right-click context menu shows up fine, it is only the sub-context menus now, primarily when I go to close all the tabs to the right, that menu is on my first monitor.

Thanks for the report. We'll look into this and will file a new bug to address the issue. I'll link the bug new here.