Sway: Menus and some tooltips shown only once with xwayland

[cg9999]

I see issue where some of the menus and tooltips are displayed only once and after they are dismissed they won't be displayed again. Sometimes switching to another windows fixes this.

For example here I opened xfce-terminal, and clicked help menu, log displays:

handle:9 type:3 state:0 parent:8 mask:0 (x:705 y:68 w:147 h:56) title:Xfce Terminal class:xfce4-terminal appid:(null)
Adding unmanaged window 0x18efe00 to 0xf0a7c0
geometry request for 9 147x56 @ 705,68

Menu appears, now clicking on terminal window to close the menu.

Destroying window 9
Setting focus to 0x18efcb0:8 (VIEW 'Terminal')

After this clicking the help menu does nothing and nothing on the log, but clicking other menues work, but also just one single time

sway is 0.3 release version
wlc is git r913.2a9a7d0 (latest)

[robotanarchy]

This might be related to is probably a duplicate of Cloudef/wlc#104:

• Open Firefox
• First, a tooltip gets displayed fine
• Second time, the tooltip just doesn't show up
• Third time (and all following), it looks like on the screenshot.
• When restarting Firefox, the first tooltip is normal again etc.

[cg9999]

Thanks @robotanarchy, it looks somehow related.

I've debugged this a bit further:

It seems this consistently happens only when wlc is build as RelWithDebInfo (not in Debug).
I also set WLC_DEBUG=xwm to get more data

Clicking menu first time, menu works:

[debug_log.c:95] Setting focus to 0x15861d80:2 (VIEW 'Terminal')
[main.c:43] [wlc] XCB_PROPERTY_NOTIFY (4194308)
[main.c:43] [wlc] XCB_CREATE_NOTIFY (4194411 : 1)
[main.c:43] [wlc] -> Unpaired collisions (0)
[main.c:43] [wlc] XCB_CONFIGURE_NOTIFY (4194411)
[main.c:43] [wlc] XCB_CLIENT_MESSAGE
[main.c:43] [wlc] XCB_MAP_NOTIFY (4194411)
[main.c:43] [wlc] XCB_CLIENT_MESSAGE
[main.c:43] [wlc] -> Surface resource for x11 window (4194411) does not exist yet
[main.c:43] [wlc] -> Paired collisions (0)
[main.c:43] [wlc] -> Linked x11 window (4194411) to view (3) [159x50+253,66]
[main.c:43] [wlc] -> Configure x11 window (4194411) 159x50+253,66
[handlers.c:210] handle:3 type:3 state:0 parent:2 mask:0 (x:253 y:66 w:159 h:50) title:Xfce Terminal class:xfce4-terminal appid:(null)                                                                                                
[handlers.c:272] Adding unmanaged window 0x159ff260 to 0x16131160
[main.c:43] [wlc] -> Configure x11 window (4194411) 159x50+253,66
[handlers.c:343] geometry request for 3 159x50 @ 253,66
[main.c:43] [wlc] -> Configure x11 window (4194411) 159x50+253,66

Dismissing menu:

[main.c:43] [wlc] XCB_PROPERTY_NOTIFY (4194308)
[main.c:43] [wlc] XCB_UNMAP_NOTIFY (4194411)
[main.c:43] [wlc] XCB_UNMAP_NOTIFY (4194411)
[handlers.c:280] Destroying window 3
[debug_log.c:95] Setting focus to 0x15861d80:2 (VIEW 'Terminal')

Clicking menu again, menu does not appear:

[debug_log.c:95] Setting focus to 0x15861d80:2 (VIEW 'Terminal')
[main.c:43] [wlc] XCB_PROPERTY_NOTIFY (4194308)
[main.c:43] [wlc] XCB_CLIENT_MESSAGE
[main.c:43] [wlc] XCB_MAP_NOTIFY (4194411)
[main.c:43] [wlc] XCB_CLIENT_MESSAGE
[main.c:43] [wlc] -> Surface resource for x11 window (0) does not exist yet

Something sets the win->id to 0...

[robotanarchy]

I guess your best bet is to ask @Cloudef in IRC if he can help you to debug/fix this.
As I wrote in the other ticket, he suggested a bisect (trying to find out which commit actually introduced this bug). Maybe you can do that and report it to him, so he can fix it.

[ddevault]

I can reproduce this.

[codebam]

Can confirm, same thing with GIMP as well

[scarejar]

This problem seems not only limited to GTk applications but qt applications too.

[tasn]

@scarejar, I've seen it in VirtualBox, which is a Qt application, so can confirm. It really just happens everywhere for me.

[ddevault]

I believe this is fixed on the latest wlc+sway.

[tasn]

You're correct. It's fixed. Maybe close this ticket?

[ddevault]

I want to get a couple more people to confirm.

[nightmared]

You're right, the problem no longer appears in firefox (with the latest version of wlc and sway from github). Thanks a lot, it was very annoying. ;)

[soredake]

Still happens to me in firefox with last versions wlc+sway

[ddevault]

Fuck this issue

[ceesco53]

These are my dropdown menu issues.

example1: Right click in xfce4-terminal and the menu does not work on hover, but cursor keys work.
example 2:Right click in xfce4-terminal and the menu does not work on hover, but cursor keys work. Move mouse to another tile and back. Menu works with mouse.
example3: Drop down main menu in virtualbox doesn't receive click.
example4: Right click menu in chromium doesn't receive click regardless of actions.

I'm running latest wlc + sway git on arch.

[PluMGMK]

This was fine for me for a long time. But I think whatever seems to have fixed it for some people (i.e. the change that got this issue closed) brought it back for me.
Basically, whether or not an XWayland app (either Qt5 or GTK3) gives me a menu is random, with the probability decreasing as I continue using menus. Occurs in Thunderbird and VirtualBox, which are important to me, but also any other app (eg. GIMP, but that can be run under Wayland anyway).

[m1cr0man]

I have the exact same symptoms as @ceesco53, but I'm running sway 0.8-2 from the community repos with wlc 0.0.4-1

The right-click menus are definitely appearing now, unlike before I upgraded wlc, but similarly I can't navigate them with the mouse.

Sublime Text 3 and GIMP's drop down menus still only show once, and their right click menus are being weird in different ways (Sublime's always appears but mouse doesn't work, GIMP's appears once but mouse works)

I don't mind this too much, tbh I use keyboard navigation for 99% of things anyway. Being able to see what I'm doing is good enough!

[ceesco53]

I deleted all my environment overrides for GTK/GNOME/wayland from my .zshrc and all my dropdown menus are working as intended. I'm not sure which one caused the problem or if it was upgrading my wlc/sway to the latest git commits today...

[ddevault]

It was the latter. That was fixed by wlc today.

[ceesco53]

Fosspay sent. Thank you.

[ddevault]

Thanks!

[VoidNoire]

I still experience this issue. It happens for me with Firefox tooltips, menu bar menus and right click context menus. It also happens with context menus and menus from the menu bar on PCManFM. It doesn't happen when I right click on files/folders on PCManFM though or with its file/folder tooltips. Additionally, the issue does happen with the menus from the menu bar on Leafpad but not with the context menu. I am on sway-0.9-1 and wlc-0.0.5-1.

[ddevault]

I've noticed this with Firefox as well, notably the Tor browser bundle. Paging @Cloudef

[automat0n]

@VoidNoire I had the same issue. I swapped the repo version for the git version and that solved it.

[alive4ever]

I can confirm that with sway-git and wlc-git, the context menu and menu bar dropdown issue solved.

However, the dropdown suggestion from Firefox address bar didn't show up as expected. The Firefox address bar suggestion is shown as plain small rectangle with no visible text.

Is Firefox address bar suggestion related to this issue?

[onny]

alive4ever: I guess its related to this issue: XWayland popups are poorly sized https://github.com/SirCmpwn/sway/issues/731

[esphen]

Still seeing this on Firefox Gentoo with both stable 0.9 and sway-9999 and wlc-9999. Has been present for a while, not a recent regression. Menus show once and not until a new window is created.

$ sway -v
sway version 0.10-rc1-11-gd2aba3c (2016-10-03, branch "HEAD")

What is strange is that the menus seem to be _behind_ the main window. If I click the hamburger menu and move the mouse to where the buttons are supposed to be, I see nothing, but I am able to click them to open windows and whatnot.

Please note that this works flawlessly on Fedora with sway and wlc from copr.

[jhalmen]

i confirm that switching to the git versions fixed the issue with menus and tooltips.
still had the problem with arch community builds sway 0.9-1 and wlc 0.0.6-1

[Ant59]

Updated to the sway-git package from the AUR which fixed the issue in Firefox. Still occurs in other applications such as Atom, where the drop down menus cease to work more than once. However I did notice that if the Atom window is floating, the menus show up fine, albeit in the wrong place.

➜  ~ sway -v
sway version 0.10-rc1-52-g47fd538 (2016-10-24, branch "makepkg")

[onny]

Same issue for me, had more luck with the git version ....
sway 0.10-1
wlc 0.0.7-1

[logankaser]

@onny Same versions as you, same issue on Void Linux.

[m1cr0man]

I have been having this issue for a while now. I reloaded my laptop this weekend (ArchLinux x64, Intel GPU if that makes a difference). I used wlc-git and sway-git from AUR, giving me versions 0.0.7-r5 and 0.10-rc1-59 (2016-10-30) respectively.

I ran GIMP as a test, as it had huge problems with context menus and drop downs not appearing. It now works flawlessly :smile: I am going to blame the fact that I moved from the AUR package to the community version back when I started using sway, and probably didn't uninstall them right. I was very very careful with my package selection this time around, so if anyone wants to see my setup commands I'll happily share them.

[ddevault]

Guys, if anyone wants to see this issue resolved you're gonna have to dig in and figure it out. A dozen people saying they can reproduce it isn't half as helpful as one person figuring the damn problem out.

[ghost]

Commenting line 508 in wlc's src/compositor/view.c makes the menus work for me. Both sway and wlc are from the current master.
I don't have programming experience with Wayland/Sway/X at all, so please double check.

diff --git a/src/compositor/view.c b/src/compositor/view.c
index 77277bf..95dde59 100644
--- a/src/compositor/view.c
+++ b/src/compositor/view.c
@@ -505,7 +505,7 @@ void
 wlc_view_focus_ptr(struct wlc_view *view)
 {
    if (view && (view->type & WLC_BIT_UNMANAGED))
-      return;
+      //return;

    if (view)
       wlc_x11_window_set_active(&view->x11, true);

[robotanarchy]

Hey thanks for trying to fix this, @chel8413!

I guess you did not intend to do this, but as far as I know with your patch, the remaining code works the following way (probably _not_ intended):

    if (view && (view->type & WLC_BIT_UNMANAGED))
    {
        if (view)
           wlc_x11_window_set_active(&view->x11, true);
    }

So when you want to render the if-condition useless, comment out both lines (or delete them, as dead code is not really a good thing):

    // if (view && (view->type & WLC_BIT_UNMANAGED))
        // return;

@chel8413: Does commenting out the whole if-codition also fix it for you?

@SirCmpwn, @Cloudef: Does the fix look legit, or is this just randomly avoiding the race condition?

[ghost]

@robotanarchy yes, you are right, that was not intended. I tested and noticed that the menues work out of the box using the current master as @m1cr0man mentions. Probably I didn't check with the current wlc-master before doing the change... my apologies for the confusion.

[evbogue]

I just encountered this issue in Gimp while using the sway and wlc packages in Arch Linux. Upgrading to sway-git and wlc-git from AUR fixed the issue.

[robotanarchy]

After dealing a long time with the issue:

• It is reproducible for me (and for probably everyone in this ticket), when running the stock Arch Linux packages.
• Using the git version (eg. from AUR) always "fixes" the issue. But not, because it is fixed, but because you're compiling a bit different - and thus the race condition does not get executed.

I guess this is obvious already to @SirCmpwn and @Cloudef, but it is probably not obvious to everyone else. So again: installing the git version is a workaround that randomly works, but it does not fix the issue!

The obvious difference between the AUR PKGBUILD and the ABS PKGBUILD is for both sway and wlc: -DCMAKE_BUILD_TYPE=Upstream (AUR) vs. -DCMAKE_BUILD_TYPE=Release (ABS). So the bug gets triggered with the Release config only, as I see it.

EDIT: @aereaux has already written this down here: https://github.com/Cloudef/wlc/issues/104#issuecomment-211114850

[ddevault]

Can someone clarify which (one or both) of wlc and sway can be built from source to "fix" the issue?

[automat0n]

It is a problem from wlc. If you install sway from arch repos, then install wlc-git from aur the issue is solved. Maybe some bisection can tell us which commit solved it.

[ddevault]

Bisect won't help. It's a difference with how it's built, not a bug introduced in a specific commit. Next step: can someone turn wlc logging up to 11 and show a comparison of two sway logs with and without the bug?

[robotanarchy]

I have created some log files, with a diff. @SirCmpwn, can you take a look at them?

versions

sway: 0.10-1
wlc: 0.0.7-1
wlc-git: 0.0.7.r7.gb5bf9e4-1

steps

for each log file:

• run sway

export WLC_DEBUG=handle,render,render-loop,focus,xwm,keyboard,commit,request
sway -d -V > logfile 2>&1

• run dmenu (via hotkey combination)
• start geany
• click on "File"
  
  
  
  • menu opens
  
  
  • menu is focused
  
  
• click on "File"
  
  
  
  • menu closes
  
  
  • focus back to geany
  
  
• click on "File" another time
  
  
  
  • menu opens
  
  
  • menu is focused
  
  
  • (BUG!) release build only: menu is invisible
  
  
• click on "File"
  
  
  
  • menu closes
  
  
  • focus back to geany
  
  
• run dmenu via shortcut
• type in "killall sway"

generate the diff (remove timestamps, colorized diff, add line numbers, convert to html):

cat log_wlc.txt | cut -d '-' -f 2- > log_wlc_notimestamp.txt
cat log_wlc-git.txt | cut -d '-' -f 2- > log_wlc-git_notimestamp.txt
colordiff -y -W 150 log_wlc_notimestamp.txt log_wlc-git_notimestamp.txt | cat -n | ansi2html > diff.html

files

• colorized diff (left: wlc, right: wlc-git)
• log_wlc.txt
• log_wlc-git.txt

[onny]

I'm using sway 0.11 stable from the ArchLinux repo now and it works as long as I use the wlc-git package from the AUR (wlc stable reintroduces this issue)

[airstep]

I'm using wlc from ABS (ArchLinux) and just change 'Release' word to 'Upstream' - and menu shows as expected. But I found another issue with mouse pointer - that disapear when using with Visual Studio Code as an example. When I move from opened file place to folder tree it often hide mouse pointer... And I need to switch to other workspace and move mouse to make it visible again.

Mouse theme is: Pulse-Glass

Also, often - dialogs shows behind main window - example: chromium (even attach this file). And I need to resize dialogs manualy - can it be configurable?... And how to position dialogs to center of the screen to prevent random positions...

My configuration file in atach...
config.txt

[ddevault]

This is a 45-comment-strong issue about something else. Open a new one.

[ddevault]

Two new ones.

[ebdmuir]

I know he's gonna create a new issue and i can repeat this there but the exact same thing happens to me, i will go into additional detail when he creates the new issue else I'll do it in a little bit

[rolfen]

I'm having an issue with the right click contextual menu in Firefox, the right click event seems to be fired when I press and when I release the button. The thing is, I'm using Weston, no wlc or sway.

I saw the same bug in in sway.

I often see issues with mis-aligned menus, and had a random issue with the menu appearing beneath the window (very useful...) but it seems to have gone away in the latest update.

Firefox under Gnome(Wayland) seems to work well and not exhibit this promplem.

Again, this is not sway/wlc - but it might help.

[ddevault]

This has been fixed in the wlroots branch. :tada: