Open Bug 1592416 Opened 5 months ago Updated 19 days ago

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

Categories

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

70 Branch
x86_64
macOS
defect

Tracking

()

People

(Reporter: yoachim, Unassigned, NeedInfo)

References

(Blocks 2 open bugs)

Details

Attachments

(3 files)

Attached image 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.

Component: Untriaged → Menus
OS: Unspecified → macOS
Hardware: Unspecified → x86_64

: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?

Flags: needinfo?(yoachim)
Flags: needinfo?(spohl.mozilla.bugs)

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.

Flags: needinfo?(yoachim)

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

Blocks: catalina
Component: Menus → Widget: Cocoa
Product: Firefox → Core

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

Duplicate of this bug: 1593521
Summary: Firefox bookmark toolbar and right-click menu only appear on Desktop 1 in mac OS Catalina → Right click opens menu on the first monitor (Desktop 1) instead of second monitor in mac OS Catalina

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/

Flags: needinfo?(spohl.mozilla.bugs) → needinfo?(yoachim)
(In reply to Stephen A Pohl [:spohl] from comment #6)

mozregression dies with:

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

mozregression dies with:

Flags: needinfo?(yoachim)

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

Flags: needinfo?(dr_who)

(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...

Flags: needinfo?(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.

Flags: needinfo?(yoachim)

(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!

Flags: needinfo?(dr_who) → needinfo?(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.

Flags: needinfo?(yoachim)

(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...

Flags: needinfo?(spohl.mozilla.bugs)

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.

Flags: needinfo?(spohl.mozilla.bugs) → needinfo?(dr_who)
Duplicate of this bug: 1594772

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

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.

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

Keywords: regression
Keywords: regression

(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. :-\

Duplicate of this bug: 1598361
Priority: -- → P2
Duplicate of this bug: 1600205
Summary: Right click opens menu on the first monitor (Desktop 1) instead of second monitor in mac OS Catalina → Right click opens context menu on wrong monitor (mac OS Catalina)
Status: UNCONFIRMED → NEW
Ever confirmed: true
Summary: Right click opens context menu on wrong monitor (mac OS Catalina) → Right click opens context menu on wrong monitor or virtual desktop (mac OS Catalina)
Duplicate of this bug: 1603961
Duplicate of this bug: 1610187

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

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).

Duplicate of this bug: 1610784
See Also: → 1610784
Duplicate of this bug: 1611147
Duplicate of this bug: 1611650
Duplicate of this bug: 1611698
Duplicate of this bug: 1614757
Blocks: 1604027
Duplicate of this bug: 1611243

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

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.

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)

(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!

(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.

You need to log in before you can comment on or make changes to this bug.