1984812 - [GNOME 49.1] Holding right click no longer selects options in context menus on Wayland Linux

Status: RESOLVED MOVED

(Core :: Widget: Gtk, defect, P3)

Description

[Dragoon Aethis]

Attachment: 2025-08-23 11-53-58.mkv

User Agent: Mozilla/5.0 (X11; Linux x86_64; rv:142.0) Gecko/20100101 Firefox/142.0

Steps to reproduce:

Pressing the right mouse button opens the context menu, but on Linux, you can hold the right mouse button, move the pointer over the item you want to select, then release the right mouse button to invoke that item.

Actual results:

As of Firefox 142, this no longer happens in all context menus, especially in the webpage content, on tabs, etc. (It still works for some menus, like the context menu on the empty space in the bookmark bar, or on the hamburger menu in the toolbar.)

While trying to hover over options on the context menu, items in the toolbar in the upper left corner get highlighted (but do not get invoked if the right mouse button is released). A video of this behavior is attached.

Expected results:

The hold-select-release flow works universally in all context menus, like it did before FF 142.

Comment 1

[Dragoon Aethis]

Attachment: about-support.txt

Extra notes: This is on KDE Plasma 6.4.4 running on Wayland. The same behavior happens on a fresh profile as well (attached about:support contents from there).

Comment 2

[BugBot [:suhaib / :marco]]

The Bugbug bot thinks this bug should belong to the 'Core::Widget: Gtk' component, and is moving the bug to that component. Please correct in case you think the bot is wrong.

Comment 3

[Martin Stránský [:stransky] (ni? me)]

Can you use mozregression tool to find broken commit?
https://fedoraproject.org/wiki/How_to_debug_Firefox_problems#Use_Mozregression_tool
Thanks.

Comment 4

[Dragoon Aethis]

Using: mozregression --good 141.0.3 --bad 142.0

0:45.11 INFO: Last good revision: aeb150a06b3eeeab56a698b26d9a487c891fd7a9
0:45.11 INFO: First bad revision: 62f1dc9218204d41aabac5efc3cb0a2f193dd2d2
0:45.11 INFO: Pushlog:
https://hg.mozilla.org/releases/mozilla-release/pushloghtml?fromchange=aeb150a06b3eeeab56a698b26d9a487c891fd7a9&tochange=62f1dc9218204d41aabac5efc3cb0a2f193dd2d2

Comment 5

[Dragoon Aethis]

Additionally, running with MOZ_ENABLE_WAYLAND="0" (about:support -> Window Protocol -> xwayland) makes context menus behave properly again.

Comment 6

[Martin Stránský [:stransky] (ni? me)]

Unfortunately the regression range is quite big.

Comment 7

[Martin Stránský [:stransky] (ni? me)]

Can you try latest nightly with clean profile:
https://fedoraproject.org/wiki/How_to_debug_Firefox_problems#Testing_Mozilla_Nightly_binaries

And also different DE like Gnome?
Thanks.

Comment 8

[Dragoon Aethis]

Sorry for the delay. The issue still reproduces with Nightly 145.0a1 (2025-09-21, Linux 64-bit), Wayland only. When tested under nested KWin, the issue still reproduces, but it does not reproduce under nested Mutter.

Comment 9

[Ylvisaker]

Two important notes regarding the bug:

This only occurs in certain regions of the browser. For example if I right click, hold, and move the mouse over the context menu of the 90% left most area of the browser, you can see the mouse is actually being mapped to the left left section of the browser window. This is a bigger issue as if you let go of the mouse at just the right spot, it will trigger (though rarely it seems) the control/button that is being incorrectly moused over.

If you "jiggle" the mouse you can see it hovering the back, forwards, refresh button area. If you repeat the right click within ~20 pixels of the right most edge, the menu and mouse work as expected.

This issue did not occur in FF 141.x It only showed it's face in 142.x

Comment 10

[Ylvisaker]

Attachment: Right click context menu operates on far right section of window.

Video showing that the right click menu still functions as intended if it's on the far right, about 20 pixels, of the browser.

Comment 11

[Manuel Bucher [:manuel]]

Noticed today too. I'm on Gnome 49 Wayland. I was sure that this is a recent regression, because I believe that I regularly use the "hold right click to select context menu"-pattern. However I can reproduce with very old builds. I've tried mozreression with last week (2023-10-07) first, then a normal one with last year (2023-10-17), and also two years ago (2023-10-17). All of them were "bad" on the first build. Not sure what to make of it. For Gnome it could be a recentish regression. I did run system updates yesterday (archlinux). Didn't open a new bug, because this one exists and I'm not sure if mine is the same / even a Firefox bug.

Comment 12

[Martin Stránský [:stransky] (ni? me)]

Let's see if Bug 1992198 fixes it.

Comment 13

[Manuel Bucher [:manuel]]

Bug 1992198 doesn't fix it for me. But could still be separate bug, because I noticed much later. Please let me know if I should open a separate bug.
Same observation though MOZ_ENABLE_WAYLAND="0" fixes the hover effect (however the item doesn't get selected when releasing the mouse button).
I did a mozregression, but for me it leads to https://hg-edge.mozilla.org/mozilla-central/pushloghtml?fromchange=89aa2c8696b7b10a4e71f95d4a468171b92bb828&tochange=cc33400f0ff80f0eada6c3aa637f37d247a3ff46 (probably Bug 1749174, therefore not conclusive).
Thunderbird is the only other program where I observe the broken right click behavior.

If someone else can do a mozregression, passing mozregression --good 141 --bad 142 could lead to more fine granular results, because then it operates on Nightlies.

Comment 14

[Ylvisaker]

Launching Firefox with "MOZ_ENABLE_WAYLAND=0 firefox" does indeed fix the bug for me. However performance of Firefox is significantly worse and scrolling both websites and the tab bar is noticeably choppy, running at (estimate) 5fps.

Can you try again with MOZ_ENABLE_WAYLAND=0 firefox instead of "0"?

(In reply to Manuel Bucher [:manuel] from comment #13)

Bug 1992198 doesn't fix it for me. But could still be separate bug, because I noticed much later. Please let me know if I should open a separate bug.
Same observation though MOZ_ENABLE_WAYLAND="0" fixes the hover effect (however the item doesn't get selected when releasing the mouse button).
I did a mozregression, but for me it leads to https://hg-edge.mozilla.org/mozilla-central/pushloghtml?fromchange=89aa2c8696b7b10a4e71f95d4a468171b92bb828&tochange=cc33400f0ff80f0eada6c3aa637f37d247a3ff46 (probably Bug 1749174, therefore not conclusive).
Thunderbird is the only other program where I observe the broken right click behavior.

If someone else can do a mozregression, passing mozregression --good 141 --bad 142 could lead to more fine granular results, because then it operates on Nightlies.

Comment 15

[Manuel Bucher [:manuel]]

(In reply to Ylvisaker from comment #14)

Can you try again with MOZ_ENABLE_WAYLAND=0 firefox instead of "0"?

MOZ_ENABLE_WAYLAND=0 firefox yields the same result as MOZ_ENABLE_WAYLAND="0" firefox: The hover problem gets fixed. (Without any caviats. I don't observe the problem of items not getting selected when releaseing the mouse button anymore. They get selected as expected).

On (gnome) wayland the problem remains for me, even with the patch from Bug 1992198 applied.

Comment 16

[Markus Koller]

Same here on GNOME 49.1 / Wayland / Debian unstable:

• All context menus are affected, no matter where on the page I open them (i.e. also on the right-most side, unlike the other report above)
• Left-click menus (toolbar hamburger menu, bookmark folder menus) are also affected.
• The main menu bar (if I turn it on) is affected differently: menu items are highlighted on hover, but there's a vertical offset which seems to correspond to the GNOME top panel height (i.e. if I hover over the second menu item, the first one gets highlighted). Releasing the left mouse button successfully triggers a click on the highlighted menu item.

This happens in Firefox 144 from Debian, latest nightly, as well as mozregression going back to version 120 (didn't try older versions). MOZ_ENABLE_WAYLAND=0 does avoid the issue here too.

Other GTK 3/4 apps work correctly, i.e. highlighting works, and releasing the mouse button triggers a click on the highlighted menu item. Chromium also works correctly, although it looks like they don't use GTK for their context menus (but libgtk-3 is shown as a dependency).

Qt6 apps (using qt6-gtk-platformtheme) somewhat work: highlighting works about 50% of the time, but releasing the mouse button doesn't trigger a click at all.

Not sure if this is a regression in Firefox or GNOME, as I only just switched to Wayland for the 49 update (which drops X11 support).

Comment 17

[Martin Stránský [:stransky] (ni? me)]

Please run on terminal with MOZ_LOG="Widget:5 WidgetPopup:5" env variables and attach two logs, one for working one and one for the broken one.
Thanks!

Comment 18

[Martin Stránský [:stransky] (ni? me)]

I wonder if we fail to grab input on the popup or so.

Comment 19

[Manuel Bucher [:manuel]]

Attachment: broken-wayland.log

Comment 20

[Manuel Bucher [:manuel]]

Attachment: good-xorg.log

Comment 21

[Manuel Bucher [:manuel]]

Info: I had to change MOZ_LOG to Widget:5,WidgetPopup:5 separated by comma, otherwise log file turned out empty. (And kept timestamp,sync, in the beginning in about:logging)

Comment 22

[Martin Stránský [:stransky] (ni? me)]

Can you please also provide MOZ_LOG="Widget:5 WidgetPopup:5" from working Wayland session? (if there's any?).

Comment 23

[Manuel Bucher [:manuel]]

(In reply to Martin Stránský [:stransky] (ni? me) from comment #22)

Can you please also provide MOZ_LOG="Widget:5 WidgetPopup:5" from working Wayland session? (if there's any?).

I'll try on an older debian/ubuntu when I get the time to test it out there. (the good-xorg was recorded on the same wayland session, I think through xwayland, but I'm not an expert)

Comment 24

[Markus Koller]

Attachment: broken-wayland.log

MOZ_LOG="Widget:5,WidgetPopup:5" ./firefox &> broken-wayland.log

Comment 25

[Markus Koller]

Attachment: good-xwayland.log

MOZ_LOG="Widget:5,WidgetPopup:5" MOZ_ENABLE_WAYLAND=0 ./firefox &> good-xwayland.log

Comment 26

[Markus Koller]

For comparison I also attached two logs above, the second one with Xwayland (GNOME 49 dropped the X11 session, so I can't test that anymore).

Both are with the latest nightly and doing these steps:

1. Move mouse cursor over the first tab
2. Hold down right mouse button -> menu appears
3. Move cursor down to first menu item "New Tab to Right"
4. Release mouse cursor

Comment 27

[Martin Stránský [:stransky] (ni? me)]

Thanks for testing. Looking at it on Fedora 43 / Gnome 49 but I can't reproduce it and I have no idea what can cause it. X11 logs are not relevant here - looks like missing mouse grab over the newly created popup window.

Comment 28

[Martin Stránský [:stransky] (ni? me)]

Looks like we set the popup as transparent for input events:

[Parent 21154: Main Thread]: D/WidgetPopup [7f09211a4400]: nsWindow::SetInputRegion(1, 5)

but not sure why.

Comment 29

[Manuel Bucher [:manuel]]

Clearing needinfo, because we do have wayland and xwayland logs and there isn't a need for x11 log per comment 27

Comment 30

[Martin Stránský [:stransky] (ni? me)]

.

Comment 31

[Martin Stránský [:stransky] (ni? me)]

Looks like we really make the popup input transparent only, at least from the Wayland logs. Emilo, do you have any idea? Why do we set the popups as input transparent and not flip them back to non-transparent ones?
Thanks.

Comment 32

[Martin Stránský [:stransky] (ni? me)]

For instance from the log https://bug1984812.bmoattachments.org/attachment.cgi?id=9526287 Popup 7f09211a4400 is not set as input sensitive at all.

Comment 33

[Martin Stránský [:stransky] (ni? me)]

OTOH looking at popup 7f092b492100 which is a menu popup we set the input region as nsWindow::SetInputRegion(0, 5).

Comment 34

[Markus Koller]

(In reply to Martin Stránský [:stransky] (ni? me) from comment #32)

For instance from the log https://bug1984812.bmoattachments.org/attachment.cgi?id=9526287 Popup 7f09211a4400 is not set as input sensitive at all.

From the 360x98 size I'm guessing that's the hover preview that appears when hovering over the tab :)

Comment 35

[Martin Stránský [:stransky] (ni? me)]

If that's KDE only I'd say it's https://bugzilla.mozilla.org/show_bug.cgi?id=1993660 but the GNOME report confuses me a bit. Yes, looks like we set the input state from Gtk3 POV.

Can you please run on terminal as:

WAYLAND_DEBUG=1 MOZ_LOG="Widget:5,WidgetPopup:5" ./firefox &> broken.log

reproduce it under GNOME and attach it here? I wonder how the Wayland backend behaves.
Thanks.

Comment 36

[Markus Koller]

Attachment: broken.log

WAYLAND_DEBUG=1 MOZ_LOG="Widget:5,WidgetPopup:5" ./firefox &> broken.log

Comment 37

[Markus Koller]

Sure, here you go! Same steps as before.

I also wanted to test a nested Mutter session, following the instructions at https://fedoraproject.org/wiki/How_to_debug_Firefox_problems#Testing_different_Wayland_compositor

The --nested flag seems to be gone, but I got it working by:

1. Logging out of my GNOME session
2. Running mutter --wayland on one terminal
3. Running WAYLAND_DISPLAY=wayland-0 firefox on another terminal

Unfortunately the result is the same, i.e. menu items are not highlighted and selected when holding down the mouse button, and instead widgets of the main window are highlighted. But that should at least rule out any parts that are specific to gnome-shell vs. mutter.

Also just to make sure we're talking about the same thing: Normal usage of menus works fine (i.e. click-and-release, hover over item, left-click to select), it's only hold-click-and-release-over-item that's not working in Firefox for me. It's interesting that you can't reproduce this on GNOME 49, I'm assuming that's version 49.1 as well?

I'll also attach my about:support for comparison.

Comment 38

[Markus Koller]

Attachment: about-support.txt

Comment 39

[Martin Stránský [:stransky] (ni? me)]

Thanks. I investigated the Wayland related log and according to it we set subsurface as input-transparent and set input regions to GtkWidget owned parent wl_surface:

Popup 7f4f8ab26500:

  5 nsWindow::SetInputRegion() calls:
  1. Line 4348 ❌ No wayland call
  2. Line 4489 ❌ No wayland call
  3. Line 4566 ✅ → Line 4646 (has wayland call)
  4. Line 4703 ✅ → Line 4790 (has wayland call)
  5. Line 4858 ✅ → Line 4875 (has wayland call)

  3 wayland set_input_region() calls for wl_surface#72:
  - Line 4646: wl_surface#72.set_input_region(wl_region#81)
  - Line 4790: wl_surface#72.set_input_region(wl_region#93)
  - Line 4875: wl_surface#72.set_input_region(wl_region#95)

Comment 40

[Martin Stránský [:stransky] (ni? me)]

(In reply to Markus Koller from comment #37)

Also just to make sure we're talking about the same thing: Normal usage of menus works fine (i.e. click-and-release, hover over item, left-click to select), it's only hold-click-and-release-over-item that's not working in Firefox for me. It's interesting that you can't reproduce this on GNOME 49, I'm assuming that's version 49.1 as well?

I see. But on the screencast I see the cursor is moving over popup but toplevel is selected. In such case is mouse button hold from the menu open click? I.e. is the sequence mouse button down -> (still holding mouse button) menu open -> (still holding mouse button) hovering over popup?

Thanks.

Comment 41

[Markus Koller]

(In reply to Martin Stránský [:stransky] (ni? me) from comment #40)

I see. But on the screencast I see the cursor is moving over popup but toplevel is selected. In such case is mouse button hold from the menu open click? I.e. is the sequence mouse button down -> (still holding mouse button) menu open -> (still holding mouse button) hovering over popup?

I didn't make the screencasts, but yes the sequence is correct and I see the same behaviour where hovering over the popup menu (with the mouse button still held down) highlights UI items from the toplevel, as if it's using the coordinates of the popup menu to trigger highlights in matching coordinates on the toplevel.

Also as others pointed out (and can be seen in the second screencast) it seems to work correctly on KDE when the popup is opened on the far right side of the window, while here on GNOME that doesn't make a difference (also not in maximized/fullscreen modes).

Comment 42

[Martin Stránský [:stransky] (ni? me)]

That's interesting, I can't reproduce that. Testing on Fedora 42 / Gnome 48. I'll try on Gnome 49 and KDE later.

Comment 43

[Martin Stránský [:stransky] (ni? me)]

Tested on Fedora 43 / Gnome and I can reproduce, indeed.

Comment 44

[Kestrel]

Confirming GNOME 49.1 regression (Fedora 43 live USB), GNOME 49.0 unaffected (Ubuntu 25.10). Not a Firefox regression, all versions affected with native Wayland going back to 2020.

Context menus unaffected with widget.gtk.native-context-menus = true although too many items are shown.

Comment 45

[Markus Koller]

GNOME 49.2 just landed in Debian unstable, can confirm it's still affected as well.

Also found this possibly related MR in Mutter, which got merged for 49.1: wayland: Do not force pointer focus on popups

Comment 46

[Martin Stránský [:stransky] (ni? me)]

Okay, let's move it then.

Comment 47

[Manuel Bucher [:manuel]]

This is still happening to me on Gnome 50, which likely has the mutter fix applied (hasn't stopped in-between).

$ mutter --version
mutter 50.1

Do we need to reopen or open another issue on gnome gitlab?

Comment 48

[Dragoon Aethis]

With KDE 6.6.4 (KWin Wayland), Gtk 3.24.52 and Firefox 150.0 (using native Wayland), the hold-and-release-to-select behavior works once again! I'm not sure where exactly and due to which component upgrade it started to work again though.

Comment 49

[Martin Stránský [:stransky] (ni? me)]

(In reply to Manuel Bucher [:manuel] from comment #47)

This is still happening to me on Gnome 50, which likely has the mutter fix applied (hasn't stopped in-between).

$ mutter --version
mutter 50.1

Do we need to reopen or open another issue on gnome gitlab?

Yes please.

Comment 50

[Manuel Bucher [:manuel]]

I was about to open a bug report for mutter. However, while doing so I noticed that there potentially has been some miscommunication in this bug that I'd like to clear up before opening a bug externally. It seems like comment 45 speculates that this regression was introduced in in mutter!4703. I currently read comment 46 roughly as "this is likely fixed by mutter!4703" leading to this bug being closed (AFAICT).

The bug is only observable on gecko-based application for me (Firefox and Thunderbird) and all other applications behave normal to me. Due to mutter!4703 mentioning that the change makes it more compliant with the wayland specification, I'm not so certain anymore that this is a bug that should be fixed in mutter (I have drafted the issue, so there wouldn't be much trouble to open it and link here).

@stransky: Could you aid assess whether this should be fixed in Gecko?

Comment 51

[Martin Stránský [:stransky] (ni? me)]

Will check when I rebase to Fedora 44 / mutter 50.

Comment 52

[ales.astone]

Testing on mutter 50.1, WAYLAND_DEBUG confirms that mutter is sending wl_pointer::enter events on the correct surface (the subsurface on top of the xdg-popup), so this is not on the mutter side and it is not about input regions either.

Comment 53

[Manuel Bucher [:manuel]]

Let's reopen this bug for now to track here.

Comment 54

[Martin Stránský [:stransky] (ni? me)]

Looks like this affects Gnome only, KDE works as expected. Running on Fedora 44 / mutter-50.1-1.fc44.x86_64 and I still see this bug. Until the mouse button is released the focus / events are delivered to toplevel window instead of the popup. When mouse button is released, input comes to the popup.

Comment 59

[Martin Stránský [:stransky] (ni? me)]

Yes, looks like the enter is generated when popup is shown (not sure what's discarded there?)

[4127847.707] {Default Queue} wl_surface#90.enter(wl_output#38)
[4127847.710] {Default Queue} wl_surface#90.enter(wl_output#6)
[4127847.713] {Default Queue} discarded wl_surface#66.enter(wl_output#38)
[4127847.715] {Default Queue} discarded wl_surface#66.enter(wl_output#6)

but it's emitted by Gtk3 when mouse button is lifted:

[Parent 70136: Main Thread]: D/WidgetPopup [7f18a971ba00]: enter notify (win=7f18940e8980, sub=0): 74.72, 141.97 mode 2, detail 0
[Parent 70136: Main Thread]: V/WidgetPopup [7f18a971ba00]: nsWindow::FractionalScaleFactor(): fractional scale 1.33
[Parent 70136: Main Thread]: D/WidgetPopup [7f18a971ba00]: OnEnterNotify

Comment 60

[Martin Stránský [:stransky] (ni? me)]

I wonder why I don't see it on KDE.

Comment 61

[ales.astone]

@stransky you're looking at the wrong wayland "enter" events: we're interested in the pointer entering the surface, not in the surface entering the output display.

Comment 62

[ales.astone]

Since I only started experiencing this recently, I wonder if it is indeed a recent regression in GTK3.

Comment 64

[Markus Koller]

It seems like comment 45 speculates that this regression was introduced in in mutter!4703. I currently read comment 46 roughly as "this is likely fixed by mutter!4703" leading to this bug being closed (AFAICT).

Sorry yes I should have clarified that this was pure speculation on my part!
My thinking was that Mutter changed their behavior in that MR to be more in line with the Wayland spec, which broke some expectations/assumptions on the Firefox side.

I also remember that a comment in that MR mentioned that KDE doesn't behave the same, which would explain that discrepancy:

FWIW, kwin_wayland and sway don't implement the protocol like this, but weston does.

And this comment mentioned that some changes were needed in GTK to adapt to the new behavior:

I don't mind implementing the spec to-the-word in this way. But then let's fix GTK to handle it correctly, shall we?

From what I can tell both GTK3 and GTK4 were "fixed" though, as I can't reproduce the issue with any GTK3 app besides Firefox. I tried GIMP, dconf-editor, gcolor3, and a bunch of others. But since Firefox AFAIK is doing custom rendering, maybe it uses GTK3 in a way that still breaks the behavior.

FWIW Chromium also works correctly, but not sure if GTK3 is involved at all with their context menus.

Again this is all just speculation, so I apologize if these turn out to be red herrings :)

Comment 65

[ales.astone]

mutter!4703 (and later follow-ups) seem unrelated to me, because I've confirmed through WAYLAND_DEBUG=client that mutter is sending focus to the popup subsurface as expected

Comment 66

[Martin Stránský [:stransky] (ni? me)]

Yes, looks like Mutter and KDE behaves the same way now. I'm debugging it. Looks like Firefox propagates motion/enter/leave events differently on KDE and Mutter, perhaps due to previous hacks.

Comment 67

[Martin Stránský [:stransky] (ni? me)]

Looks like Mutter + Gtk3 sends wrong coordinates to Firefox:

[Parent 317717: Main Thread]: D/Widget [7fda928d9d00]: nsWindow::OnMotionNotifyEvent()
[Parent 317717: Main Thread]: D/Widget [7fda928d9d00]:   refPoint [114, 174] aEvent [57.238281, 87.246094]

[3058136.792] {Default Queue} wl_pointer#54.leave(21758, wl_surface#66)
[3058136.801] {Default Queue} wl_pointer#10.leave(21758, wl_surface#66)

[3058136.821] {Default Queue} wl_pointer#54.enter(21759, wl_surface#70, 24.23828125, 8.24609375)
[3058136.827] {Default Queue} wl_pointer#10.enter(21759, wl_surface#70, 24.23828125, 8.24609375)

[3058136.857] {Default Queue} wl_pointer#54.motion(10610641, 24.23828125, 8.24609375)
[3058136.860] {Default Queue} wl_pointer#10.motion(10610641, 24.23828125, 8.24609375)

[Parent 317717: Main Thread]: D/Widget [7fda928d9d00]: nsWindow::OnLeaveNotifyEvent() (win=7fda92497b20, sub=0): 57.24, 87.25 mode 0, detail 3
[Parent 317717: Main Thread]: D/Widget [7fda928d9d00]: OnLeaveNotify

[3058143.724] {Default Queue} wl_pointer#54.motion(10610648, 24.23828125, 9.24609375)
[3058143.727] {Default Queue} wl_pointer#10.motion(10610648, 24.23828125, 9.24609375)

[Parent 317717: Main Thread]: D/Widget [7fda928d9d00]: nsWindow::OnMotionNotifyEvent()
[Parent 317717: Main Thread]: D/Widget [7fda928d9d00]:   refPoint [-4, -28] aEvent [-1.761719, -13.753906]

Looks like Mutter generates wl_pointer#54.leave / wl_pointer#54.enter. That leads to issue nsWindow::OnLeaveNotifyEvent() on toplevel. From that point Gtk translates the coordinates nsWindow::OnMotionNotifyEvent() from popup perspective [refPoint [-4, -28]] but sends it to toplevel.

Comment 68

[Martin Stránský [:stransky] (ni? me)]

Looks like Mutter + Gtk3 sends nsWindow::OnLeaveNotifyEvent() when popup is created / opened and mouse button is hold. When mouse button is release we get nsWindow::OnEnterNotifyEvent() and coordinates are correct again.

Comment 69

[Martin Stránský [:stransky] (ni? me)]

Looks like we have a workaround for it already:
https://searchfox.org/firefox-main/rev/9c267d0a950b189974105667e9eb14d2f6172564/widget/gtk/nsWindow.cpp#6094
but may be broken?

Comment 70

[Martin Stránský [:stransky] (ni? me)]

Looks like the OnLeaveNotifyEvent() is sent twice for the toplevel:

[Parent 351306: Main Thread]: D/Widget [7fe096820b00]:   refPoint [114, 175] aEvent [57.441406, 87.804688]
[Parent 351306: Main Thread]: D/Widget [7fe096820b00]: nsWindow::OnLeaveNotifyEvent() (win=7fe096197b20, sub=0): 57.44, 87.80 mode 0, detail 3

[Parent 351306: Main Thread]: D/Widget [7fe096820b00]: nsWindow::OnMotionNotifyEvent()
[Parent 351306: Main Thread]: D/Widget [7fe096820b00]:   refPoint [-2, -27] aEvent [-0.558594, -13.195313]

[Parent 351306: Main Thread]: D/Widget [7fe096820b00]: nsWindow::OnLeaveNotifyEvent() (win=7fe096197b20, sub=0): 3.91, 25.16 mode 2, detail 0
[Parent 351306: Main Thread]: D/WidgetPopup [7fe07a5efb00]: nsWindow::OnEnterNotifyEvent() (win=7fe0658910a0, sub=0): 29.91, 48.16 mode 2, detail 0

Comment 71

[Martin Stránský [:stransky] (ni? me)]

Looks like we'd need https://gitlab.gnome.org/GNOME/gtk/-/merge_requests/9028 for Gtk3 too (If I understand it correctly).
If wl_pointer.leave generates OnLeaveNotifyEvent() now (by Gtk3) we can't do anything about it on Firefox side as the coordinates are calculated from popup perspective but sent to toplevel (parent).

Comment 73

[Martin Stránský [:stransky] (ni? me)]

Fixed on Gtk3 by https://gitlab.gnome.org/GNOME/gtk/-/merge_requests/9956