Wayland issue - Can't click inside many context menus in chromium based browsers and firefox

[thendricks0]

Windows build number:

10.0.26200.0

Your Distribution version:

24.04 (also tested with a fresh install and also tested with NixOS and Ubuntu 22.04)

Your WSL versions:

WSL version: 2.6.1.0 (also tested 2.6.2.0, 2.5.4 and 2.4.13) Kernel version: 6.6.87.2-1 WSLg version: 1.0.66 (also tried with WSLg 1.0.65 and 1.0.60) MSRDC version: 1.2.6353 Direct3D version: 1.611.1-81528511 DXCore version: 10.0.26100.1-240331-1435.ge-release Windows version: 10.0.26200.6901

Steps to reproduce:

1. Install WSL
2. Install any Distro (I tested Ubuntu 24.04, Debian and NixOS)
3. Install Google-Chrome, Brave or Firefox
4. Run export XDG_SESSION_TYPE=wayland
5. Run any browser through the terminal session which has XDG_SESSION_TYPE set to wayland

For Chromium based browsers

Try to open any extension window and then click on anything inside that window. Or try to open the extension menu (puzzle icon) and click on any extension, it won't open.

For Firefox

Try opening the burger menu and click on any menu entry, same behavior as with chrome. Or try the right-click context menu.

WSL logs:

tail -f /mnt/wslg/weston.log
[09:41:01.682] xfixes selection notify event: owner 2097153
[09:41:01.682] our window, skipping
[09:41:55.849] Client: ClientGetAppidReq: WindowId:0x26 does not have appId, or not top level window.
[09:42:07.498] xfixes selection notify event: owner 2097153
[09:42:07.498] our window, skipping
[09:42:07.895] Client: ClientGetAppidReq: WindowId:0x27 does not have appId, or not top level window.
[09:42:09.612] Client: ClientGetAppidReq: WindowId:0x28 does not have appId, or not top level window.
[09:42:09.710] Client: ClientGetAppidReq: WindowId:0x29 does not have appId, or not top level window.
[09:42:14.222] Client: ClientGetAppidReq: WindowId:0x2a does not have appId, or not top level window.
[09:42:30.155] Client: ClientGetAppidReq: WindowId:0x2b does not have appId, or not top level window.
[09:42:45.894] Client: ClientGetAppidReq: WindowId:0x2c does not have appId, or not top level window.
[09:42:49.494] Client: ClientGetAppidReq: WindowId:0x2d does not have appId, or not top level window.
[09:42:51.366] Client: ClientGetAppidReq: WindowId:0x2e does not have appId, or not top level window.

Whenever any context window is opened the message Client: ClientGetAppidReq: WindowId:... does not have appId, or not top level window. log appears but it also appears for context windows that work. stderr.log does not log anything.

After enabling WESTON_RDPRAIL_SHELL_DEBUG_LEVEL=5 in my .wslgconfig I found out that there is a very different behavior when the popup windows are outside of the main window bounds.

# WHEN CONTEXT MENU INSIDE OF WINDOW:

[09:15:44.063] handle_keyboard_focus: moving focus from 0x58ecfa6a5c30:rdprail-shell focus proxy window to 0x58ecfa6b8180:Mozilla Firefox
[09:15:44.199] Client: ClientGetAppidReq: WindowId:0x26 does not have appId, or not top level window.
[09:15:44.199] Client: ClientGetAppidReq: WindowId:0x27 does not have appId, or not top level window.
[09:15:46.558] handle_keyboard_focus: moving focus from 0x58ecfa6b8180:Mozilla Firefox to 0x58ecfa6b8180:Mozilla Firefox
[09:15:46.564] handle_keyboard_focus: moving focus from 0x58ecfa6b8180:Mozilla Firefox to (nil):(null)
[09:15:46.581] handle_keyboard_focus: moving focus from (nil):(null) to 0x58ecfa6b8180:Mozilla Firefox


# WHEN CONTEXT MENU OUTSIDE OF WINDOW:

[09:15:52.841] handle_keyboard_focus: moving focus from 0x58ecfa6a5c30:rdprail-shell focus proxy window to 0x58ecfa6b8180:Mozilla Firefox
[09:15:52.949] Client: ClientGetAppidReq: WindowId:0x28 does not have appId, or not top level window.
[09:15:52.949] Client: ClientGetAppidReq: WindowId:0x29 does not have appId, or not top level window.
[09:15:53.044] Client: ClientGetAppidReq: WindowId:0x2a does not have appId, or not top level window.
[09:15:53.113] Client: ClientGetAppidReq: WindowId:0x2b does not have appId, or not top level window.

WSL dumps:

No response

Expected behavior:

When wayland is used. Clicking on stuff inside context menus should work for all context menus.

Actual behavior:

Many context windows are not clickable, it's only possible to navigate through them with the keyboard.

What works is the Chrome menu button (three dots menu) and all sub-menus, right-click context menu works as well, opening folders and clicking on bookmarks in the bookmarks bar works. What doesn't work is opening context windows of extensions, clicking on downloads in the downloads context menu, clicking on stuff inside the profile context menu, clicking on stuff inside the "View site information" window is not possible either. Basically every "floating" window can only be opened but clicking on it is like clicking outside the window.

Firefox is even worse as you can't click any context menu at all, not even the right-click menu. The downloads window is also unusable. Navigating with the keyboard still works. The X button to close Firefox doesn't work either.

I only noticed this behavior in browsers using wayland. When starting Chrome with X11 the context menus work fine. I can reproduce this on a freshly installed WSL distro. I have no idea when this started since I had this problem for at least two to three months now and hoped that each WSL update might fix the problem. It might have been introduced with a WSL 2.5.x update but I am not sure and since I am using WSL for work it is difficult to iteratively downgrade my WSL installation. I do wonder if anyone also has this problem.

Update: I just found out that if the Firefox right-click context menu goes out of bounds (overlaps outside the firefox window into the Windows desktop), I can click every entry! I also updated the logs which show that handle_keyboard_focus log messages appear when the context menu is inside the Firefox window boundaries which are not logged when the context menu is outside of the boundaries.

Update: I also now tried to downgrade WSLg to 1.0.65 and 1.0.60 and the issue still persists, so it is likely that this issue is not even related to WSLg and has been introduced with a WSL update. And now I also downgraded to 2.5.4 and even 2.4.13 with which I am quite certain I never had this issue. Sadly the problem persists on every WSL version I tested, every WSLg version with every OS I tried (fresh installs!) but the issue still persists, so this issue might have started after a Windows update?

So I've been trying at a colleagues WSL instance and they don't have this problem so I guess my steps to reproduce are useless.

[Daemoen]

Unfortunately, this is a known issue with the Weston compositor version used in WSLg. This was originally reported in #1119 (September 2023), which identified that updating Weston to version 10+ would resolve the problem.

Current WSLg Weston Version:

$ grep 'weston' /mnt/wslg/versions.txt
weston: f227edd681479ec3cb2290a25d84d2d3462aebfa

This commit corresponds to Weston 9.0.0 (Build: 9.0.0-210-gf227edd6), released in 2020. The current upstream Weston is at version 13/14, meaning WSLg is 4-5 major versions behind - approximately 5 years out of date.

The popup/menu click handling issues affecting both Firefox and Chromium-based browsers in Wayland mode were likely fixed in Weston 10+. However, the same Weston 9.0 commit has been used across WSLg releases from v1.0.61 through v1.0.66 (latest), with no updates to the Weston codebase.

Workaround: Force browsers to use X11 instead of Wayland by setting MOZ_ENABLE_WAYLAND=0 for Firefox/LibreWolf, or XDG_SESSION_TYPE=x11 for Chromium-based browsers.

Updating WSLg's Weston fork would require Microsoft to merge years of upstream changes, rebase their custom RDP integration patches, and ship via Windows Update - a significant undertaking that doesn't appear to be prioritized.

Edit: Adding more context and formatting.

[thendricks0]

Thanks for the heads up! I don't really understand how it worked for more than a year without this issue. I definitely always used wayland since using WSL2, because the X11 titlebars are really ugly to look at.. And I tested it on the host of my colleague with Wayland and the issue didn't appear on their machine.. so there must be a condition to trigger this bug right?

[thendricks0]

Hi @Daemoen !

So I went through the trouble of rebasing the weston-mirror to weston 10.0.5 and building a new system.vhd for my WSLg. It wasn't actually that bad, I had to rebase ~200 commits of which the most changes were in the early 5 commits the rest were formatting conflicts.

I had success and now have a working version of Weston 10.0.5 as is visible in the /mnt/wslg/weston.log:

Date: 2025-11-17 CET
[08:40:19.063] weston 10.0.5
               https://wayland.freedesktop.org
               Bug reports to: https://gitlab.freedesktop.org/wayland/weston/issues/
               Build: 10.0.5-205-gea46277c
[08:40:19.063] Command line: /usr/bin/weston --backend=rdp-backend.so --modules=wslgd-notify.so --xwayland --socket=wayland-0 --shell=rdprai
l-shell.so --log=/mnt/wslg/weston.log --logger-scopes=log,rdp-backend,rdprail-shell
[08:40:19.063] OS: Linux, 6.12.57-custom-WSL2, #1 SMP PREEMPT_DYNAMIC Mon Nov  3 03:55:51 UTC 2025, x86_64
[08:40:19.063] Flight recorder: enabled
[08:40:19.063] warning: XDG_RUNTIME_DIR "/mnt/wslg/runtime-dir" is not configured
correctly.  Unix access mode must be 0700 (current mode is 0777),
and must be owned by the user UID 1000 (current owner is UID 1000).
Refer to your distribution on how to get it, or
http://www.freedesktop.org/wiki/Specifications/basedir-spec
on how to implement it.
[08:40:19.064] Using config file '/home/wslg/.config/weston.ini'
[08:40:19.065] Output repaint window is 7 ms maximum.
[08:40:19.065] Loading module '/usr/lib/libweston-10/rdp-backend.so'
[08:40:19.072] using FreeRDP version 2.4.0
Date: 2025-11-17 CET

Sadly though, the problem even persists with Weston 10.0.5... Firefox still behaves the exact same and Chrome as well. Nonetheless, would @hideyukn88 accept a PR with my rebase so my efforts at least don't go to waste?

Obviously I can't guarantee that there might be some regressions or new Weston 10 bugs that would be introduced with this, for my part I can't tell any difference in functionality between my WSLg apps after the Weston update.

If desired I'd be willing to supply PRs for later Weston versions as well, as long as it's just fixing minor conflicts between versions I think I am able to pull it off. I'm not very experienced in C though so I don't think I can fix major issues between version updates.

Edit: Alright so I tried using WSL2_WESTON_SHELL_DESKTOP=true in my .wslgconfig to check if the issue is related to the rdprail-shell only since that env var changes the shell to the desktop-shell but the problem persists there too. So v10.0.5 likely doesn't fix the issue yet. I saw that there are older tags for weston 10.0.94 so I'm a little confused as to why higher patch level versions exist that are older than the ones used in the weston 10.0 branch.