Qt's context menu pasting doesn't work between apps

[tsujan]

Describe the bug If I copy a text from a Qt6/Qt5 app and paste it into another Qt6/Qt5 app by right clicking and clicking "Paste", nothing will be pasted. If I use Ctrl+v instead, there will be no problem. GTK apps aren't affected. Also, copying from one window and pasting by right clicking in to another window of the same app is OK. Strangely enough, Qt4 isn't affected either.

EDIT: The case of Qt4 isn't strange, because Qt4 runs under xwayland.

This started to happen with Wayfire 0.9.0. Today, I upgraded to git (against wlroots 0.18.2 from Arch) and saw that the problem persisted. It happens whether I use clipman or CopyQ as the clipboard manager, and also when I kill them.

To Reproduce Steps to reproduce the behavior:

1. Copy a text from a window of a Qt6 app.
2. Paste it into the window of another Qt6 app by right clicking.
3. Nothing happens

Expected behavior The text should be pasted.

Wayfire version Latest git, compiled against wlroots 0.18.2.

[tsujan]

In case my config is needed:

wayfire-lxqt.ini.zip

[ammen99]

If GTK copy-paste works as expected, I am kinda inclined to think this is a Qt bug .. maybe you updated something else together with the Wayfire update? Wayfire definitely does not differentiate which client does the copy-paste.

[tsujan]

It doesn't happen in any other wayland compositor: labwc, kwin_wayland, niri, hyprland …

Actually, I do my works under labwc and, sometimes, kwin_wayland. Today, I missed wayfire and hoped that upgrading to its git source would fix the issue ;)

[dkondor]

Interestingly, I can reproduce this, trying to copy from Kate to Spyder (both using Qt5).

I was able to get a debug log for trying to paste into both Spyder and to gedit (where it's working) and attaching the logs (note: I've removed a buch of pointer motion and buffer update messages, but I think all relevant ones are there; logs begin with right clicking).

What I see that in both cases, after opening the context menu, Wayfire creates a new wl_data_offer object (with wl_data_device#25.data_offer + wl_data_device#25.selection). The difference is then which wl_data_offer gets used:

-- In the Spyder (Qt5) case, after clicking in the context menu, the popup is closed and then wl_data_offer#4278190082.receive is sent immediately (lines 99-104) -- In the Gedit (GTK3) case, first the popup is closed, then Gedit "waits" a bit, receives a new wl_data_offer from Wayfire (line 156), then uses this new object to receive the data (line 169)

Based on this, I'm guessing that the wl_data_offer sent by Wayfire is somehow tied to the current surface, and in the Qt case, it is maybe considered invalid when the wl_data_offer::receive event is sent after closing the popup?

Note: I have not had the time to test this on other compositors yet and actually have not idea what behavior is required by the protocol.

kate_to_gedit.log kate_to_spyder.log

[dkondor]

I looked into this with Labwc, where pasting works as expected, see the attached logs.

To me, the difference is that no additional wl_data_offer object is created when the popup menu is openend. Actually, this seems to be the more correct behavior based on the [protocol].

Strangely, with a quick search, I cannot see any place where Wayfire is creating data offers, so this is handled by wlroots? In this case this is likely a bug there.

I've also noticed an additional difference: on Labwc, no wl_keyboard::enter event is sent when the menu popup is opened (even though the menu gets the keyboard focus), while on Wayfire, this is done. So maybe creating a data offer object is also somehow related to the explicit keyboard focus change?

labwc_kate_to_gedit.log labwc_kate_to_spyder.log

[ammen99]

To me, the difference is that no additional wl_data_offer object is created when the popup menu is openend. Actually, this seems to be the more correct behavior based on the [protocol].

How do you arrive at this conclusion?

[ammen99]

I've also noticed an additional difference: on Labwc, no wl_keyboard::enter event is sent when the menu popup is opened (even though the menu gets the keyboard focus),

I have noticed that too, we didn't use to do it before and then apps would internally re-route the keyboard events to the menu. However considering that context menus often have an active grab, I am not sure why they shouldn't be focused. It is up to the clients then to figure out how pasting works when the context menu is focused.

This sounds to me like a Qt bug unless I am missing something from the protocol definitions that says that what wayfire does is wrong .. In any case, thanks @dkondor for chasing this down, I suspect that what you found is the cause of the problem. I can easily imagine why it may break Qt clients.

[dkondor]

To me, the difference is that no additional wl_data_offer object is created when the popup menu is openend. Actually, this seems to be the more correct behavior based on the [protocol].

How do you arrive at this conclusion?

I got it from here: https://wayland.app/protocols/wayland#wl_data_device:event:selection which says "Switching surface with keyboard focus within the same client doesn't mean a new selection will be sent." (sorry, forgot to actually add the link before :))

[ammen99]

I wonder whether this isn't because when we switch focus, we first clear it and then set the new focus?

[ammen99]

I believe this to be a bug in the Qt toolkit or in the application. Just asked in #wayland, and got the response that we indeed should focus the popup, as Wayfire does. I checked labwc as you mentioned it works there, labwc will not focus the xdg-popup, which is why Qt 'works' but that is not the correct behavior overall. With #2690 I am adding a workaround which 'fixes' it by restoring the old incorrect behavior. I would encourage you to submit a Qt/Application bug report, explaining that a right-click menu in wayland opens an xdg-popup, and the xdg-popup has an active grab. That in turn means the compositor can and even should give keyboard focus to the popup. When you then click on 'paste', the app maybe thinks we are pasting into the menu? Something like this would be my guess.

[ammen99]

Just in case it is not clear how to use the workaround, use:

[workarounds]
focus_main_surface_instead_of_popup = true

[tsujan]

I wanted to add this comment in June but forgot:

focus_main_surface_instead_of_popup ruins the panel and all of its popups — I mean lxqt-panel, which has a Wayfire-specific backend in its version 2.3 (released recently).

[ammen99]

@tsujan I installed lxqt-panel 2.3 but it seems to work with the option set to true. Any specific cases where it doesn't work?

[tsujan]

No popup would get the keyboard focus, especially Fancy Menu, which really needs it.

[ammen99]

@tsujan Does https://0x0.st/Kfc1.diff help?

[tsujan]

Does https://0x0.st/Kfc1.diff help?

Apparently it does, with the workaround of course: Fancy Menu and other panel popups seem OK. But please let me test it for an hour or so because there may be other things I've forgotten now (currently I'm working under LXQt+Wayfire).

[tsujan]

Found no issue. Thanks!