Unable to move Telegram window when launched on startup in Wayland GNOME 40

motoridersd commented 3 years ago

I know this bug has been around for a while, but I couldn't find an issue that described this in the existing ones. If I missed it, please link to it.

Steps to reproduce

Configure GNOME 40 to launch Telegram Desktop at startup
Try to move the window by clicking the top bar and dragging
Closing the app and opening it again fixes the issue

Expected behaviour

The window should move when dragged around with the mouse

Actual behaviour

Window doesn't move

Configuration

Operating system: Fedora 34

Version of Telegram Desktop: 2.8.4

Installation source (Linux Only) - the official website / GitHub releases / flatpak / snap / distribution package: Flatpak

Used theme: Adwaita-dark

ilya-fedin commented 3 years ago

Are you running Telegram with native Wayland or XWayland?

motoridersd commented 3 years ago

It should be native, but not sure. How can I tell? Or how can I make sure it runs in native vs xwayland

ilya-fedin commented 3 years ago

How can I tell?

Privacy & Security -> Show active sessions

motoridersd commented 3 years ago

Ok it is running in X11 (Xwayland I assume) mode, but this is also when I run it again manually and the window move works.

Is this a flatpak issue then?

ilya-fedin commented 3 years ago

I guess you're hitting bugs in Qt's CSD implementation (X11 MOVERESIZE protocol), it's also known that Qt weirdly gets input events after calling move/resize (#10348)

motoridersd commented 3 years ago

I added "env QT_QPA_PLATFORM=wayland" to the .desktop file and now I can move the window on startup. Confirmed the app is now running in wayland mode.

Unfortunately this now breaks the tray indicator.

Full line in .desktop: Exec=env QT_QPA_PLATFORM=wayland /usr/bin/flatpak run --branch=stable --arch=x86_64 --command=telegram-desktop --file-forwarding org.telegram.desktop -- @@u %u @@

This will break with an update, as the flatpak will remove the env part

ilya-fedin commented 3 years ago

Unfortunately this now breaks the tray indicator.

Make sure you have wayland compatible tray extension (not TopIcons or something like it)

I don't recommend running Telegram in native Wayland mode though, qtwayland has bad compatibility with GNOME.

motoridersd commented 3 years ago

Will Telegram Desktop ever be fully Wayland compatible natively?

ilya-fedin commented 3 years ago

Will Telegram Desktop ever be fully Wayland compatible natively?

It's a question for Qt developers, tdesktop uses Qt high level APIs

motoridersd commented 3 years ago

Ok thanks. I installed the KStatusNotifierItem/AppIndicator extension and the tray is back. I'll run it like this for now and see how that goes.

binyominzeev commented 2 years ago

Same issue by me on Xubuntu 18.04.5. No move, no resize, until restart.

ilya-fedin commented 2 years ago

I'm afraid I have no idea how to fix nor how to debug that. Maybe you can report that to your WM, so that they can check what's wrong on the lower layer?

binyominzeev commented 2 years ago

OK, I reported here:

https://gitlab.xfce.org/xfce/xfwm4/-/issues/569

ilya-fedin commented 2 years ago

Thanks. I hope someone more experienced will help to debug that.

binyominzeev commented 2 years ago

They answered that they corrected the issue in a more recent version which I can try to compile for myself, because they don't issue updates for that version (even though its called "LTS" and still alive):

https://gitlab.xfce.org/xfce/xfwm4/-/issues/569#note_34962

ilya-fedin commented 2 years ago

even though its called "LTS" and still alive

It's your distro called LTS, not xfwm, lol. You should request a backport on your distro bugtracker.

ilya-fedin commented 2 years ago

https://packages.ubuntu.com/bionic/xfwm4

ilya-fedin commented 2 years ago

I'm not sure they determined the cause right, though. AFAIK, Qt should send a _NET_WM_MOVERESIZE message when starting window move, I don't think it's related to drag'n'drop. If you can reproduce this only when Telegram is autostarted, that could mean that there's some race condition between Qt and xfwm. You can try to add e.g. sleep 5 to the autostart command and see whether it help or not.

binyominzeev commented 2 years ago

Thank you! I reported here:

https://bugs.launchpad.net/ubuntu/+source/xfwm4/+bug/1937317

Regarding the suggested experiment, sorry, I lack both the time and the experience for this. (Besides, my intention was simply to report a bug, not to correct it.)

ilya-fedin commented 2 years ago

Regarding the suggested experiment, sorry, I lack both the time and the experience for this. (Besides, my intention was simply to report a bug, not to correct it.)

Well, you can't just report it and go out, that's not how that works. You should answer to questions and do requested actions to help to find the cause. Or the issue will be closed with 'no answer' reason.

binyominzeev commented 2 years ago

I confirmed a bug that was reported already. Then reported it already on two other sites. So I did already a lot of things.

Now should write sleep 5 – where exactly?

ilya-fedin commented 2 years ago

So I did already a lot of things.

You should understand that this not enough to be solved. And since I can't reproduce the issue here on Manjaro with Xfce 4.16, your assistance is required.

Now should write sleep 5 – where exactly?

~./config/autostart, you should see tdesktop's autostart file. Exec line should contain the path to the binary, change it to Exec=/bin/sh -c "sleep 5; PATH_TO_BINARY" (you should replace PATH_TO_BINARY with the actual path, of course).

I confirmed a bug that was reported already.

looks like initial reporter fixed it for himself, so you're the only affected now.

binyominzeev commented 2 years ago

Excuse my ignorance, but I could not find a file named autostart in this repository. I did:

bz@bz-HP-Laptop-15-bs1xx:~/tdesktop-dev$ find . | grep auto

But I think that if you indeed were unable to reproduce on Xfce 4.16, then the problem should indeed resolve by the update mentioned above (since I have 4.12). And I reported already where you suggested to update, so maybe currently waiting would make more sense.

ilya-fedin commented 2 years ago

Excuse my ignorance, but I could not find a file named autostart in this repository. I did:

I said you to find tdesktop's desktop file in ~/.config/autostart folder, repository has nothing to do with this

binyominzeev commented 2 years ago

Indeed, thank you! I changed, I'll report what will happen on next restart.

binyominzeev commented 2 years ago

Fantastic, the window is moving! Thank you!

ilya-fedin commented 2 years ago

Hmm, I guess Xfce autostarts applications earlier than _NET_SUPPORTED property is estabilished by Xfwm. In case of GNOME Wayland, that can be even when autostart is not involved since (IIRC) it launches Xwayland on demand (so race condition could be at any time if Telegram is the app that launched Xwayland)

https://github.com/qt/qtbase/blob/5.15/src/plugins/platforms/xcb/qxcbwindow.cpp#L2359-L2361

ilya-fedin commented 2 years ago

So, I filed a Qt bug report https://bugreports.qt.io/browse/QTBUG-95338

ghost commented 2 years ago

Is this the same issue?

https://user-images.githubusercontent.com/23178554/146662158-7c1c4447-b577-4155-a801-3d8e864bee8c.mp4

It happens after every sleep, log out and suspension.

OS: Manjaro Linux x86_64 Host: Aspire VX5-591G V1.08 Kernel: 5.15.7-1-MANJARO Uptime: 49 mins Packages: 1448 (pacman) Shell: zsh 5.8 Resolution: 1920x1080 DE: GNOME 41.2 WM: Mutter WM Theme: Adwaita-maia-compact-dark Theme: Adwaita-maia-compact-dark [GTK2/3] Icons: Papirus-Dark-Maia [GTK2/3] Terminal: gnome-terminal CPU: Intel i5-7300HQ (4) @ 3.500GHz GPU: Intel HD Graphics 630 GPU: NVIDIA GeForce GTX 1050 Mobile Memory: 3970MiB / 7818MiB

ilya-fedin commented 2 years ago

Is this the same issue?

Nothing happens on your video :thinking:

ghost commented 2 years ago

@ilya-fedin I thought it was just for me. 😓

And also "wasted" 1 hour trying many screen recorders out, finally Kooha worked for me. Screen recording, specially on Wayland, is hard. Lol.

Anyway, I've updated my post!

ilya-fedin commented 2 years ago

I use vokoscreenNG, but I'm on X11, I guess you can use OBS on Wayland.

I can't say whether it's the same issue or not though, I never reproduced this since I don't use GNOEM and don't use Wayland.

ghost commented 2 years ago

Any way I can help trace this bug? I can easily reproduce this. All I have to do is log out and in into my session.

ilya-fedin commented 2 years ago

Well, the bug seem to be in Qt's QWindow::startSystemMove/QWindow::startSystemResize methods, so I have no idea how you can help, you can try to ask Qt developers on Qt bug tracker

stale[bot] commented 2 years ago

Hey there!

This issue was inactive for a long time and will be automatically closed in 30 days if there isn't any further activity. We therefore assume that the user has lost interest or resolved the problem on their own.

Don't worry though; if this is an error, let us know with a comment and we'll be happy to reopen the issue.

Thanks!

telegramdesktop / tdesktop