1564076 - [Wayland] context menus not shown once deactivating external monitors

Status: RESOLVED DUPLICATE of bug 2036975

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

Description

[Michaël Defferrard]

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

Steps to reproduce:

Using Firefox 67.0.4 with Sway 1.1.1 on Arch. Wayland activated by setting MOZ_ENABLE_WAYLAND=1 in ~/.profile.

1. Open FF with laptop monitor and two external monitors.
2. Disable the external monitors.

Actual results:

Once the external monitors are disabled, FF doesn't show any context menu anymore (neither on right click, toolbar items, etc.).

Note that:

• Context menus are shown again once the external monitors are reactivated.
• Context menus are shown if FF is opened with the laptop monitor alone. (They disappear when I activate then deactivate the external monitors.)

Expected results:

Context menus should be shown in all circumstances.

Comment 1

[mceier]

The bug is still happening in 2026. I have 2 monitors, my 1st monitor started to "shutdown" randomly and whenever it happens and I power it on again, the context menus in firefox stop showing up - exactly they're either invisible or sometimes show up in top left corner of the 2nd screen while firefox is on 2nd screen; moving firefox between screens does not fix it.

I see a lot of:

(firefox-default:152422): Gdk-WARNING **: 08:21:35.214: Couldn't map window 0x7f3d19bf87a0 as subsurface because its parent is not mapped.
[Parent 152422, Main Thread] WARNING: Couldn't map window 0x7f3d158ddda0 as subsurface because its parent is not mapped.: 'glib warning', file ~/home/sources/firefox-hg/mozilla-unified/toolkit/xre/nsSigHandlers.cpp:201

messages in terminal when it happens.

I doubt this is GDK/GTK bug, since it only happens in firefox. I wanted to take a look at how wayland events are handled, but I have no idea where to look. Also I think it might be bigger architectural change - since I have suspicion that firefox pre-creates context menus and just maps them when they're needed and does not recreate them when output gets destroyed, causing GDK error messages above - but this is wild guess on my part.

Comment 2

[mceier]

After adding MOZ_LOG=Widget:5,WidgetWayland:5,WidgetCompositor:5,WidgetScreen:5 to environment, I got:

[Parent 149079: Main Thread]: D/WidgetScreen ScreenHelperGTK::RequestRefreshScreens()
[Parent 149079: Main Thread]: D/WidgetScreen ScreenGetterGtk::Finish() [7fba1d8c0880]
[Parent 149079: Main Thread]: D/WidgetScreen ScreenGetterGtk()::ScreenGetterGtk() [7fb9eddb0d80] HDR only [0] monitor num 2
[Parent 149079: Main Thread]: D/WidgetScreen HDR Protocol missing
[Parent 149079: Main Thread]: D/WidgetScreen MakeScreenGtk() Monitor [0] scale 1 aIsHDR 0
[Parent 149079: Main Thread]: D/WidgetScreen   workarea [1920, 0] -> [1920 x 1080]
[Parent 149079: Main Thread]: D/WidgetWayland nsWaylandDisplay::GetMonitorConfig() 1920, 0 missing!
[Parent 149079: Main Thread]: D/WidgetScreen New monitor 0 size [0,0 -> 1920 x 1080] depth 24 scale 1.000000 CssScale 1.000000  DPI 85.724998 refresh 60 HDR 0]
[Parent 149079: Main Thread]: D/WidgetScreen MakeScreenGtk() Monitor [1] scale 1 aIsHDR 0
[Parent 149079: Main Thread]: D/WidgetScreen   workarea [0, 0] -> [0 x 0]
[Parent 149079: Main Thread]: D/WidgetWayland nsWaylandDisplay::GetMonitorConfig() 0, 0 matches
[Parent 149079: Main Thread]: D/WidgetScreen   MonitorConfig pixel size [0, 0] -> [1920 x 1080]
[Parent 149079: Main Thread]: D/WidgetScreen New monitor 1 size [0,0 -> 0 x 0] depth 24 scale 1.000000 CssScale 1.000000  DPI 96.000000 refresh 0 HDR 0]
[Parent 149079: Main Thread]: D/WidgetScreen ScreenGetterGtk::AddScreen() [7fb9eddb0d80]: Set screens, serial 2 HDR only 0
[Parent 149079: Main Thread]: D/WidgetScreen Refresh screens
[Parent 149079: Main Thread]: D/WidgetScreen Refreshing all ContentParents

and based on this log, it seems that gdk_screen_get_monitor_workarea in widget/gtk/ScreenHelperGtk.cpp returns workarea of size 0x0 for some reason. I guess that's one of the reasons why firefox fails to display context menus on 2nd screen.
I wonder if firefox is calling gdk_screen_get_monitor_workarea too early or if it is GDK bug.

Comment 3

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

Can you try latest nightly please? I've fixed a similar one recently.
https://fedoraproject.org/wiki/How_to_debug_Firefox_problems#Testing_Mozilla_Nightly_binaries
Thanks.

Comment 4

[mceier]

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

Can you try latest nightly please? I've fixed a similar one recently.
https://fedoraproject.org/wiki/How_to_debug_Firefox_problems#Testing_Mozilla_Nightly_binaries
Thanks.

How recently? I am on nightly - the MOZ_LOG lines are from firefox 151.0a1 (2026-04-07).
Right now I'm building nightly from today, but your commits from Apr 7 and Apr 9 doesn't seem to be related to this bug.

I think what happens is that on sway, firefox processes wayland events before GDK does, and event handler asks GDK about the workarea geometry, before GDK was able to update it. I think firefox should handle GDK "geometry" property change signal of GdkMonitor to fix this issue or use the values from wayland events. I haven't tried implementing either solution yet.

Comment 5

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

2026-04-07 may be recent enough although I don't have the bug # handy. Will look at it then.
Thanks.

Comment 6

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

Can you run with WAYLAND_DEBUG=1 MOZ_LOG="WidgetScreen:5 and attach the log here?
Thanks.

Comment 7

[mceier]

Attachment: WAYLAND_DEBUG=1 MOZ_LOG=WidgetScreen:5 firefox log

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

Can you run with WAYLAND_DEBUG=1 MOZ_LOG="WidgetScreen:5 and attach the log here?
Thanks.

Yeah, attached log. I ran firefox, disabled one of the outputs and enabled it.

Comment 8

[mceier]

Attachment: 0001-Try-to-handle-screen-change-signal-on-wayland.patch

Implemented a hack - the patch adds handling of "monitors-changed" and "notify::resolution" GDK signals in wayland backend in similar way to X11. This works for me.

Comment 9

[Jere Kulmala]

I started experiencing this bug after updating to firefox 150 with a single monitor. I use swayidle to power off my monitor after 180 seconds of idling and often when I come back context menus and the application menu stop working. I can reproduce it by turning off my monitor for 30 seconds with sway output HDMI-A-2 power off ; sleep 30; sway output HDMI-A-2 power on . Moving firefox to another monitor (in my case I create a headless output and move it there) and back makes context menus work again.

Comment 10

[pokkos]

(In reply to Jere Kulmala from comment #9)

I started experiencing this bug after updating to firefox 150 with a single monitor. I use swayidle to power off my monitor after 180 seconds of idling and often when I come back context menus and the application menu stop working. I can reproduce it by turning off my monitor for 30 seconds with sway output HDMI-A-2 power off ; sleep 30; sway output HDMI-A-2 power on . Moving firefox to another monitor (in my case I create a headless output and move it there) and back makes context menus work again.

I can confirm the same behavior since upgrading to firefox 150. After my monitor powers off (through swayidle) no context menus are shown, but are apparently being created as other functionality like scrolling is blocked until you click somewhere else or hit the esc button.

Moving the window to another monitor fixes this behavior also for the not moved windows.

I have the same behavior with firefox nightly but not with for example librewolf based on firefox 150.

Comment 11

[klo.2k4]

Attachment: screenshot_20260429-184247.png

I too hit this issue after 150 (Ubuntu 24.04); <select> position is way off after switching from single to dual monitor (screenshot attached).

For now, work-around via xwayland:

flatpak override --user --nosocket='wayland' org.mozilla.firefox

I can also replicate issue in Ubuntu 26.04 in VM.

I'm on FF 150.0.1 flatpak in both cases.

Comment 12

[pokkos]

(In reply to mceier from comment #8)

Created attachment 9571510 [details] [diff] [review]
0001-Try-to-handle-screen-change-signal-on-wayland.patch

Implemented a hack - the patch adds handling of "monitors-changed" and "notify::resolution" GDK signals in wayland backend in similar way to X11. This works for me.

I can confirm that this patch fixes this issue on the current mainline (commit c8d15cb1b359a07625177debe620406d7fad06ac), where this issue still persists.

Comment 13

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

Please try latest nightly:
https://fedoraproject.org/wiki/How_to_debug_Firefox_problems#Testing_Mozilla_Nightly_binaries
Thanks.

Comment 14

[pokkos]

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

Please try latest nightly:
https://fedoraproject.org/wiki/How_to_debug_Firefox_problems#Testing_Mozilla_Nightly_binaries
Thanks.

I can't reproduce this error in the latest nightly. Thanks for the fix.

Comment 15

[mceier]

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

Please try latest nightly:
https://fedoraproject.org/wiki/How_to_debug_Firefox_problems#Testing_Mozilla_Nightly_binaries
Thanks.

I also confirm that the bug seems to be fixed in the latest nightly (without my patch).

Comment 16

[klo.2k4]

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

Please try latest nightly:
https://fedoraproject.org/wiki/How_to_debug_Firefox_problems#Testing_Mozilla_Nightly_binaries
Thanks.

+1 - also fixed for me, thanks for the fix!

Comment 17

[ilvez]

Also affected. Will this land on some patch version to 150 or this goes through full cycle? 151? 152?

Comment 18

[ilvez]

Glad I tested it out on Nightly as well. So fix for my case seems to be partial.

Reproduced regression on FF 150.0.1-1 and 150.0.2-1 (Debian forky/sid, sway 1.11/wlroots, two monitors at fractional scale 1.25). FF 149.0.2-1 with the same setup is clean.

repro:
swaymsg output <NAME> disable
sleep 3
swaymsg output <NAME> enable
right-click anywhere in a Firefox window

MOZ_LOG="Widget:5" shows the broken pattern on 150.0.2: every popup after the re-enable gets moz_container_wayland_size_allocate ... 0,0 -> 1 x 1 followed by moz_container_map / wayland_map_event and no subsequent size_allocate. Popup stays at 1×1
indefinitely.

Tested today's Nightly with the same trigger: not fully fixed. The 1×1 allocation still happens on every popup. ~20ms later FF runs WaylandPopupHide/Close/Validate, calls moz_container_unmap + moz_container_map on the same popup, and then a real size_allocate arrives — i.e. it's a recover-after-detect path, not a prevention. Visible as a brief flicker.

Recovery isn't 100%: at least one popup in my Nightly trace (size_allocate 1×1 at t=06:33:05.105) never received a follow-up resize and was Reproduced regression on FF 150.0.1-1 and 150.0.2-1 (Debian forky/sid, sway 1.11/wlroots, two monitors at fractional scale 1.25). FF 149.0.2-1 with the same setup is clean.

repro:
swaymsg output <NAME> disable
sleep 3
swaymsg output <NAME> enable

Glad I tested it out on Nightly as well. So fix for my case seems to be partial.

Reproduced regression on FF 150.0.1-1 and 150.0.2-1 (Debian forky/sid, sway 1.11/wlroots, two monitors at fractional scale 1.25). FF 149.0.2-1 with the same setup is clean.

repro:
swaymsg output <NAME> disable
sleep 3
swaymsg output <NAME> enable

right-click anywhere in a Firefox window

MOZ_LOG="Widget:5" shows the broken pattern on 150.0.2: every popup after the re-enable gets moz_container_wayland_size_allocate ... 0,0 -> 1 x 1 followed by moz_container_map / wayland_map_event and no subsequent size_allocate. Popup stays at 1×1
indefinitely.

Tested today's Nightly with the same trigger: not fully fixed. The 1×1 allocation still happens on every popup. ~20ms later FF runs WaylandPopupHide/Close/Validate, calls moz_container_unmap + moz_container_map on the same popup, and then a real size_allocate arrives — i.e. it's a recover-after-detect path, not a prevention. Visible as a brief flicker.

Recovery isn't 100%: at least one popup in my Nightly trace (size_allocate 1×1 at t=06:33:05.105) never received a follow-up resize and was Reproduced regression on FF 150.0.1-1 and 150.0.2-1 (Debian forky/sid, sway 1.11/wlroots, two monitors at fractional scale 1.25). FF 149.0.2-1 with the same setup is clean.

repro:
swaymsg output <NAME> disable
sleep 3
swaymsg output <NAME> enable
right-click anywhere in a Firefox window

MOZ_LOG="Widget:5" shows the broken pattern on 150.0.2: every popup after the re-enable gets moz_container_wayland_size_allocate ... 0,0 -> 1 x 1 followed by moz_container_map / wayland_map_event and no subsequent size_allocate. Popup stays at 1×1
indefinitely.

Tested today's Nightly with the same trigger: not fully fixed. The 1×1 allocation still happens on every popup. ~20ms later FF runs WaylandPopupHide/Close/Validate, calls moz_container_unmap + moz_container_map on the same popup, and then a real
size_allocate arrives — i.e. it's a recover-after-detect path, not a prevention. Visible as a brief flicker.

Recovery isn't 100%: at least one popup in my Nightly trace (size_allocate 1×1 at t=06:33:05.105) never received a follow-up resize and was unmapped 650ms later when focus moved away. Not yet sure which code path skips the remap.

Trigger is purely wl_output global destroy + re-advertise — no hardware/DRM event required, no scale change required (scale stays 1.25 across the cycle in my trace). Mixed scales (1.0 + 1.25) and matched scales (1.25 + 1.25) both reproduce on 150.0.2.

Can attach MOZ_LOG captures from 150.0.2 (broken), 149.0.2 (clean), and Nightly (partial recovery) if useful. nmapped 650ms later when focus moved away. Not yet sure which code path skips the remap.

Trigger is purely wl_output global destroy + re-advertise — no hardware/DRM event required, no scale change required (scale stays 1.25 across the cycle in my trace). Mixed scales (1.0 + 1.25) and matched scales (1.25 + 1.25) both reproduce on 150.0.2.

Can attach MOZ_LOG captures from 150.0.2 (broken), 149.0.2 (clean), and Nightly (partial recovery) if useful.

MOZ_LOG="Widget:5" shows the broken pattern on 150.0.2: every popup after the re-enable gets moz_container_wayland_size_allocate ... 0,0 -> 1 x 1 followed by moz_container_map / wayland_map_event and no subsequent size_allocate. Popup stays at 1×1
indefinitely.

Tested today's Nightly with the same trigger: not fully fixed. The 1×1 allocation still happens on every popup. ~20ms later FF runs WaylandPopupHide/Close/Validate, calls moz_container_unmap + moz_container_map on the same popup, and then a real
size_allocate arrives — i.e. it's a recover-after-detect path, not a prevention. Visible as a brief flicker.

Recovery isn't 100%: at least one popup in my Nightly trace (size_allocate 1×1 at t=06:33:05.105) never received a follow-up resize and was unmapped 650ms later when focus moved away. Not yet sure which code path skips the remap.

Trigger is purely wl_output global destroy + re-advertise — no hardware/DRM event required, no scale change required (scale stays 1.25 across the cycle in my trace). Mixed scales (1.0 + 1.25) and matched scales (1.25 + 1.25) both reproduce on 150.0.2.

Can attach MOZ_LOG captures from 150.0.2 (broken), 149.0.2 (clean), and Nightly (partial recovery) if useful. nmapped 650ms later when focus moved away. Not yet sure which code path skips the remap.

Trigger is purely wl_output global destroy + re-advertise — no hardware/DRM event required, no scale change required (scale stays 1.25 across the cycle in my trace). Mixed scales (1.0 + 1.25) and matched scales (1.25 + 1.25) both reproduce on 150.0.2.

Can attach MOZ_LOG captures from 150.0.2 (broken), 149.0.2 (clean), and Nightly (partial recovery) if useful.

Comment 19

[ilvez]

Sorry about the spammy entry. Can't edit. Something in the preview made the stuff appear multiple times. Please delete it I can repost :(

Comment 20

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

Yes, looks like we'd need to introduce the monitor-change signal somehow to get the workarea.