Wayland + Multiscreen + Fractional Scaling: Conext menus may not accept input

[chermnyx]

Steps to reproduce

1. Configure screens as following

2. Use the following scaling configuration:

3. Open Telegram on the bottom screen and maximize it's window

4. Open a chat and right-click on the message on top

Expected behaviour

The context menu should be able to accept left click on selected buttons

Actual behaviour

Context menu shows up and shows the selected item properly but the left mouse key is not handled by the context menu

The issue happens only on right-click context menus opened by cursor on the top part of a display (when the menu needs to be shifted bottom relative to the cursor position in order to fit on the screen). If clicked on the bottom part of a display, the context menus work as expected.

Operating system

ArchLinux, KDE Plasma 6.0.1

Version of Telegram Desktop

4.15.1

Installation source

Flatpak

Crash ID

No response

Logs

No response

[ilya-fedin]

Can I reproduce this without having a second monitor? I don't have one.

[chermnyx]

Can I reproduce this without having a second monitor? I don't have one.

I can reproduce it with a virtual display:

1. Open OBS and configure it to use PipeWire screen capture
2. In KDE's portal dialog select "new virtual output"
3. In screen settings set the new output to be on top of the existing one + enable fractional scaling

[ilya-fedin]

Why do you think it's a tdesktop bug? It really sounds like a KDE or Qt bug.

[chermnyx]

Why do you think it's a tdesktop bug? It really sounds like a KDE or Qt bug.

It might be related to xdg-output patch in qt

I haven't experienced the described behavior in other QT apps so far

[ilya-fedin]

Yeah, it might be... Although it sounds really weird cause I don't remember anything in qt or tdesktop prohibiting input that way (I remember the other way around problems though: when Qt was interpreting the input from the underlying window like from the items of the menu that were initially there, before the WM moved it) :thinking: Can you reproduce with default interface scale or with 100% chosen in tdesktop?

[chermnyx]

Fractional scaling on bottom screen enabled:

• tdesktop 100% - can reproduce
• tdesktop default scaling - can reproduce

Fractional scaling on bottom screen disabled: Can't reproduce with any setting in tdesktop

[ilya-fedin]

Can you reproduce with the precise scaling option from the experimental settings?

[chermnyx]

Can you reproduce with the precise scaling option from the experimental settings?

No, but the pictures become blurry/pixelated

[ilya-fedin]

ok, disable the experimental option, can you reproduce with QT_QPA_PLATFORM=xcb and your preferred scaling value in tdesktop?

[chermnyx]

No, works fine on xwayland (other than NVIDIA's flicker bug)

[ilya-fedin]

ok, now try with experimental option enabled + xcb

[chermnyx]

Can't reproduce the bug with xcb+experimental but there are nvidia's flicker & pixelated pictures

[ilya-fedin]

No, but the pictures become blurry/pixelated

That's with GL disabled, right? If yes, try without QT_QPA_PLATFORM=xcb, with the experimental option enabled and with GL enabled.

[chermnyx]

Icons are fine with GL enabled & xcb, context menus are fine Icons get pixelated with the "precise scaling" option

Flickering only happens on xcb (because of NVIDIA)

The current issue only reproduces on wayland backend

Changing opengl option seem to do nothing on both xcb & wayland backends

[ilya-fedin]

Icons get pixelated with the "precise scaling" option

They shouldn't be pixelated with both GL & precise scaling on Wayland (but not on X11 or without GL). Are you sure checked that combo?

[chermnyx]

Icons get pixelated with the "precise scaling" option

They shouldn't be pixelated with both GL & precise scaling on Wayland (but not on X11 or without GL). Are you sure checked that combo?

My bad I had "opengl for media" disabled with the experimental option for nvidia opengl enabled

it's fine with the precise scaling & wayland & opengl; can't reproduce the issue

[ansipunk]

It looks like the issue is gone after I disconnected and reconnected the screen, problem is not there anymore after Telegram restart. I'll test later if it will stay that way after a restart and if the problem will persist, I'll create another issue. I don't have an NVIDIA GPU though so I imagine the problem is somewhere else. Looking at logs I posted in #27575, I assume Telegram is incorrectly getting scaling settings despite GNOME doesn't support fractional scaling by default.

UPD: Problem reappeared after a reboot.

[ilya-fedin]

I can reproduce it with a virtual display:

1. Open OBS and configure it to use PipeWire screen capture

2. In KDE's portal dialog select "new virtual output"

3. In screen settings set the new output to be on top of the existing one + enable fractional scaling

I can indeed reproduce that way with the stable version that uses Qt 6.6.2 but can't with the beta version that uses Qt 6.7.0. Can you check it?

[chermnyx]

I still can reproduce on beta, but the affected area became smaller

On telegram beta (https://github.com/telegramdesktop/tdesktop/releases/tag/v4.15.4) only when the menu covers the system window decoration it stops accepting clicks (like on the screenshot below); also it's now not 100% reproducible and may accept all the clicks except for the very top of the menu

The menu also might get placed in the wrong place on the screen

the top of the "set wallpaper" or the entire button does not register clicks

[ilya-fedin]

I had to enable Qt window frame to get this reproduced, I was unable to reproduce with the out of the box settings (and perhaps wouldn't be able to get an idea that this is required without the screenshot). The menu is also no that far away from the right edge for me.

I remembered what the initially reported behavior was looking like: the lack of window focus in Qt PoV. The menu was showing the hover effect but no reaction to the left click and no animations which should be triggered by cursor moves.

The behavior of the new Qt is weirder, though.