Context menu shows under the task bar (if the right click is performed at a certain, "sensitive", position)

[cristian-spiescu]

Windows build number:

10.0.22000.0

Your Distribution version:

20.04

Your WSL versions:

WSL version: 1.0.3.0 Kernel version: 5.15.79.1 WSLg version: 1.0.47 MSRDC version: 1.2.3575 Direct3D version: 1.606.4 DXCore version: 10.0.25131.1002-220531-1700.rs-onecore-base2-hyp Windows version: 10.0.22000.1281

Steps to reproduce:

1. Open an app w/ context menu. In my case, VS Code (running within WSL; not running in Windows + WSL bridge).
2. Right click => context menu opens. Then right click a few pixels down. Etc.
3. When the right spot is found, we can see that the menu is hidden underneath the task bar.

WSL logs:

No response

WSL dumps:

No response

Expected behavior:

No response

Actual behavior:

Either the menu should display on top of the taskbar. Or move it a bit up. Idea is not to have hidden menu entries.

NOTE, w/ an X server such as X410, this does not happen.

[hideyukn88]

@cristian-spiescu, thanks for reporting the issue. Given taskbar is at topmost at Windows side, the solution should be adjust window position to make pop up window entirely visible, while other top level window can go behind taskbar, so the behavior should be unique to pop up window. And this is not specific to taskbar, but to screen edge as well, reported at https://github.com/microsoft/wslg/issues/641, and this case, not just screen boundary, but it has to be bound by work space area (which is screen minus task bar area), thanks!

[cristian-spiescu]

Hi there. Are there any plans to fix this small but annoying-enough-to-stop-using-wslg? I see that #641 that you are mentioning will soon have it first 1 year birthday...

As a side note, I retry on a regular base wslg, hoping that these kind of issues are fixed. I think a lot of WSL users wait for those remaining 5% of WSLG to be finished.

[hideyukn88]

@cristian-spiescu, thanks for inquiring the status. Currently I have been trying to understand "who" supposed to be in charge of adjusting context/popup menu location.

For example, I pick some GTK popup menu samples (from https://zetcode.com/gui/gtk2/menusandtoolbars/) and run it on native Ubuntu desktop with mutter compositor (now in Wayland mode by default with Ubuntu 22.04 Desktop release), and placing their taskbar at bottom, I do see similar overlapping issue.

Also, by running Wayland native samples, below is weston-terminal, on Ubuntu 22.04 Desktop release, the popup is overlapping taskbar as well.

These seems indicating that the adjustment is not done by its window manager, but more application specific or framework specific. Of course, this type of overlapping doesn't happen with gedit (which is also on GTK) and other mature/non-sample type applications on Ubuntu desktop release, but it does happen with WSLg, thus something is missing in WSLg. I was thinking to simply do its adjustments in our window-manager/shell, but based on how Ubuntu desktop behaves as described above, I'm not really sure done in window-manager/shell is right.

In case anyone know more understanding at this area, please share your thoughts, thanks!

[cristian-spiescu]

My 2 cents on this:

1/ We use X410 which doesn't have this issue. My impression is that it's a VcXsrv w/ a couple of small corrections. For example, I recall (I may be wrong) that the context menu issue was present in VcXsrv, but it doesn't appear in X410. Copy/paste was buggy in VcXsrv (i.e. after a while it stopped working, needing a restart of the X server); but fixed in X410.

2/ I understand that Wayland (compared to X) is a modern and conceptually more robust/clean approach. But my impression is that "someone "in the chain (app, wayland server, etc) doesn't play the game by the rules. Hence the issue that you are describing, i.e. even on a default Ubuntu 22.04 there is this issue, which is annoying.

3/ As an extention of 2, when we tried WSLg, we tried to deactivate Wayland. E.g. Eclipse had more issues w/ Wayland, compared to X. E.g. the resize/double arrow cursor was not displaying when hovering over split/separators. Also, the title bar (in Windows) was primitive: no maximize/minimize button, etc.

So cf. 2 and 3, I tend to think that Wayland is not "stable" enough even in the native mode. Whereas X seems more mature.

BTW, I'm happy about your answer. At least it lets me think that the project, WSLg, is not abandoned. We adopted at our organization level WSL, and we have about 95%+ of our dev activity inside WSL. About half of it happens in Eclipse + other tools that need X. And half of it happens in VS Code, w/ the WSL extension. If feedback "from the trenches" is needed to polish WSLg, I and my colleagues would be more than happy to help using our use cases, that seem to (dis)cover a lot of (small but annoying) issues.

[hideyukn88]

@cristian-spiescu, I did more research on this. For GTK applications running on Ubunu desktop, if popup menu is created by newer gtk_menu_popup_at_pointer() API instead of deprecating gtk_menu_popup() API, then it honors the taskbar (see below screenshot). I will look into GTK more on how they obtain screen/desktop space boundary and what's missing in WSLg, thanks!

[cristian-spiescu]

Great that you are finding things! My screenshot comes from VS Code. I speculate that Electron is the one calling GTK API. However, I'd say that Electron / VS Code are quite modern apps. I would have expected from them to not call deprecated API.

My remark is valid IF what I reported == what you reproduced. I used VS Code. You used a custom app.

[cristian-spiescu]

Hi there. Is there any update? I have given a try again at WSLg, w/ the latest versions (WSLg 1.0.51) but this issue still persists.

[cristian-spiescu]

I also tried with Eclipse in 2 modes:

1/ WAYLAND disabled. X11 mode. I have the same behavior. I.e. the context menu is under the taskbar. But it doesn't exit the screen.

2/ WAYLAND enabled. The context menu is shown under the taskbar. But it also exits the screen area. Below an animated gif showing the issue. I switched the taskbar in mode "auto hide".

[xuanswe]

Same thing happens to my IntelliJ IDEA and other WSLg applications. Workaround: move the task bar to the top of the screen and waiting for the fix.

[gvl2023]

Patiently waiting into the second year for a fix. This is something that I run into on a daily basis. 🙏