Dancing windows on sway

[stacyharper]

Describe the bug

When my mouse is over some parts, the windows start dancing in i3/sway.

As you can see in the demonstration, in fullscreen mode (second part), everything seems ok.

To reproduce

• Use Chatterino on i3 or sway WM

Demonstration

https://dav.misterbanal.net/pub/720de968-50a0-4d53-b889-4614ca5472a7.flv

Chatterino version

Chatterino 2.1.7 (commit )

Operating system

VoidLinux, up to date.

[Mm2PL]

Cannot reproduce on i3-gaps on Ubuntu 19.04.

[leon-richardt]

It appears to be happening whenever a popup window is opened. I think this would also explain the behavior in fullscreen: the popup windows do not need to be laid out as the fullscreen window hides them anyway.

I cannot reproduce on i3-gaps either. Is there anything relevant in your i3 config that could be relevant?

[stacyharper]

Okay my bad ! It seems it works correctly on i3. I see the popup message at the left.

The bug seems to only occurs on sway.

Is there a way to disable this popup?

[pajlada]

I'm unable to reproduce this using a fresh unconfigured sway + Xwayland setup (can't get chatterino to run without using Xwayland)
if you have any tips for how to help me who's new to sway/wayland how to reproduce this, I can look further into it

[stacyharper]

can't get chatterino to run without using Xwayland

I can but I dunno what tips to give.

What is the graphical lib behind chatterino? I think it's Qt so you'll have to install qt5-wayland

ps: I don't have any special env variable nor special Qt5 config file. It should works OOTB

[tollyx]

Ran into this as well, using sway on Arch.

You can force Qt5 to use wayland by setting the env var QT_QPA_PLATFORM to wayland. So try reproducing it by running this in a sway session:

QT_QPA_PLATFORM=wayland chatterino

The issue seems to be that sway thinks that the popups you get when hovering the channel name (and other things) are proper windows and tries to tile them accordingly.

For now I'm just running chatterino through xwayland which seems to work fine.

[stacyharper]

I'm unable to reproduce this using a fresh unconfigured sway + Xwayland setup (can't get chatterino to run without using Xwayland)

Maybe you have to install qt5-wayland ?

[pajlada]

I managed to reproduce it with
QT_QPA_PLATFORM=wayland chatterino

[pajlada]

I created a branch which fixes it for me: @Eluminae https://github.com/Chatterino/chatterino2/tree/wayland-sway-tooltip-test could you try it out?
If you can't build it, I can get an AppImage for you (if that works)
Would also love to get some other linux person to try it out on their setup to make sure this doesn't break their workflow, because this works for me using X11 and i3

[ilya-zlobintsev]

Popups work correctly on sway with the branch. You also can't move the user info window though.

[tollyx]

I also tried it out, can confirm that it fixes the 'dancing windows'.

There's minor difference I noted though - the emote/badge tooltips does not follow the cursor like they do when running through xwayland, they stay in place where they appeared instead. But unlike before it's functional.

Can also confirm that the user info window cannot be moved when running on sway/wayland (also true on the master branch though).

[stacyharper]

Yeah it is way better ! Nice work. I tested it some minutes but it seems to works as well as the xwayland version.

I detected a crazy random bug with the three dot drop down top right menu with it position

bugged menu screencast

I use scaling on sway (1.6) so maybe the position is misscomputed (maybe?)

[syphoxy]

I wanted to test the above mentioned branch since I basically had to either use xwayland, which looks like garbage to me because I use a hidpi display or deal with chatterino having a pretty major UI bug.

I rebased on master to check if it had gone stale. everything built successfully. as indicated above, the issue has disappeared and overall the experience is much smoother now.

I'm not sure what @ilyazzz and @tollyx means when they say that they can't move the user info window. it opens up for me and gets tiled immediately like you'd expect in sway. I can float it and it becomes movable by virtue of the window manager.

I haven't tried Chatterino in X11 so I don't know what the moving tooltips look like but I definitely don't think it's problematic enough to delay pushing this fix into master. I think adding a TODO is sufficient enough to address that concern.

I also can confirm the bug @Eluminae exhibited above. I happen to also be using 1.6x scaling in sway but when I tried setting it to 1x the issue still materialized. that said, it seems to only ever happen once per execution per tab so it's potentially a tab initialization issue.

---

just as I was about to wrap up writing this comment, I discovered a weird issue. it appears that the tooltips don't work unless QT_QPA_PLATFORM=wayland is explicitly set. I'm pretty sure this is currently autodetecting as wayland already so I'm not sure what the difference is here but tooltips and menus stop working when that isn't set at runtime.

and another issue ... irrespective of the QT_QPA_PLATFORM variable being set, it appears that my IME is broken in the new branch. it works in the master branch and it doesn't work on the wayland tooltips branch before or after rebasing on master.

[syphoxy]

I feel like my head is spinning. after more troubleshooting I no longer need QT_QPA_PLATFORM=wayland to be explicitly set and my IME is now working correctly ... but I haven't made any code changes. I worried that maybe there was a cached object somewhere but even after deleting and compiling from scratch doesn't manifest the issue again. I think I was chasing my tail on environment variables being not set or being unset during troubleshooting.

everything works as expected. thanks for the fix.

[pajlada]

Thanks for all the input everyone - I'm merging the https://github.com/Chatterino/chatterino2/tree/wayland-sway-tooltip-test branch into master now. Please feel free to reopen this if I closed it in mistake, and open a new issue for any other issues you run into that are sway-related!

[ilya-zlobintsev]

The issue seems to be still present when chatterino window isn't focused: video showcase

The user info window behavior is indeed what @syphoxy described with the latest build so that's resolved.

[syphoxy]

sorry to have to come back to this but I recently upgraded from Fedora 31 to Fedora 32 and it seems like the issue has partially returned.

the windows aren't dancing and most hovers appear to work properly but the menu does not work properly. at first, it opens in the wrong place, like discussed above, but in later invocations it appears to .. not appear at all.

that said, it doesn't appear to be rendering at all according to Chatterino itself. in previous builds, despite not showing a menu, it would still absorb one click if you tried to click away. it doesn't appear to do that now which makes me feel like it's not rendering whatsoever, not just not rendering correctly according to Wayland. I could be wrong about this. it's just a theory.

I've tried tweaking the flags applied to tooltips but that may be a red herring because dropdown menus are likely not "tooltips". I've looked through the menu related code in SplitHeader.cpp but I didn't find any similar calls to setWindowFlags.

is there a better way I can help debug this?

[pajlada]

Please provide a video of more dancing

[syphoxy]

@pajlada as I said, the window isn't dancing. the menu does not render when the three dots hamburger menu is pressed.

I can provide a video of this if I must but it's very much that simple. is there something else I can do to help debug this or is a video capture the best way to diagnose it?

[syphoxy]

@pajlada

here are two different manifestations of this bug. it appears to only manifest itself once during the lifecycle of a tab.