Created attachment 169728 [details] Both screenshots The "Paste special" dialog in Calc that, among other things, lets you transpose your clipboard, seems to not be available under Wayland. On the exact same installation, the "Paste special..." command (triggered either by CTRL+SHIT+V or the context menu) under Xorg brings up the usual dialog (screenshot 1), but under Wayland, brings up a dialog to select the type of content to paste (screenshot 2) and after confirming pastes it immediately, without giving you the actual "Paste special" dialog. Effectively, this makes it impossible to transpose data on Wayland (without using array formulas). Expected behavior: at least if the users selects "LibreOffice Spreadsheet" in the type dialog, the proper "Paste special" dialog should be displayed before pasting the data. More info about the environment: WM: Kwin Wayland 5.20.5 DE: KDE Plasma 5.20.5 Wayland: 1.19.0 Xorg: 1.20.10
Hi Caolán, do you reproduce this issue on your end ?
Seems to work ok for me under wayland+GNOME+Fedora 33. Starting with a blank calc spreadsheet, fill 1 into A1 and select it, ctrl+c then ctrl+shift+v I get the expected calc-specific paste special with transpose option dialog. If I ctrl+c some text in firefox and ctrl+shift+v into calc I get the other "generic" paste special dialog as expected. Do you get this unexpected paste dialog even if you copy and paste within the same calc window ?
After some additional testing, I've managed to reproduce it on two devices, both running Arch Linux and KDE Plasma. The issue also happens when running from AppImage, so the Arch build of LibreOffice is not the problem. However, on those same devices, when running under Sway instead of Plasma, the issue isn't present. I also couldn't reproduce it on KDE Neon, so the trifecta here seems to be: Arch Linux + KDE Plasma + Wayland. I plan to set up a fresh install of Arch to try and isolate the issue, but it'll be a few days before I have the free time to do that. And yes, it happens when I copying withing the same window.
I can confirm it reproducing on Arch Linux with Kernel 5.11, KDE Plasma 5.21, QT 5.15, x86_64 and Wayland. However, if I use it with SAL_USE_VCLPLUGIN=gtk3_kde5 libreoffice --calc, the menu appears and works as expected. The only missing thing for me are the keyboard shortcuts mapped to specific options in the menu, e.g. t for transpose.
Created attachment 170963 [details] Pictures showing that it works using SAL_USE_VCLPLUGIN extension
My comment #2 was with gtk3 vclplug. I am able to reproduce under wayland with SAL_USE_VCLPLUGIN=kf5 but not with SAL_USE_VCLPLUGIN=gtk3 or SAL_USE_VCLPLUGIN=gtk3_kde5 or SAL_USE_VCLPLUGIN=gen It might be that under kf5 on wayland that libreoffice isn't detecting that it is pasting from itself and treating the paste operation as being pasted in from an external application or something of that nature. For gtk3 under wayland there was a possibly similar bug of https://bugzilla.redhat.com/show_bug.cgi?id=1350478 worked around with https://cgit.freedesktop.org/libreoffice/core/commit/?id=88f7aae022bedd61588424a11bbc033217ba4e43 which might be relevant
I reproduced this with "weston --xwayland" and QT_QPA_PLATFORM=wayland. My Debian buster is too old, so "kwin_wayland --xwayland" just crashes LO. Actually just "make debugrun" made LO to start without a SIGSEGV, which doesn't look like the old KDE Wayland memory corruption bug :-( But I digress... Debugging shows, that Wayland generates two QClipboard::changed events, one after LO sets the clipboard and one a bit later. AFAIK the 2nd one is not triggered by LO directly, but I didn't try to debug Qt. Both have LO set as owners of the clipboard, but the previous assumption of the code, "set clipboard == one notification event", is broken by this, so the 2nd notification is actually handled as lost ownership, so LO won't handle it using the "internal" clipboard, resulting multiple bugs. Pending patch: https://gerrit.libreoffice.org/c/core/+/113617 That fixes the bug for me and generally looks more correct and simpler, code-wise. Hope that doesn't introduce other problems; the clipboard code is a bit fragile and took quite some time to get "right".
*** Bug 140774 has been marked as a duplicate of this bug. ***
After re-testing bug 112368, all the nice cleanup had to be reverted :-( Finding a working rule to ignore the unneeded notifications turned out a bit tricky (not really unexpected, if you remember the time it took me to "understand" and implement clipboard + D'n'D handling with Qt in LO).
Jan-Marek Glogowski committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/core/commit/71471a36b125f6bdc915d5dbcae92ebcaa7ff5a4 tdf#140404 Qt ignore "unchanged" clipboard events It will be available in 7.2.0. The patch should be included in the daily builds available at https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: https://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
Jan-Marek Glogowski committed a patch related to this issue. It has been pushed to "libreoffice-7-1": https://git.libreoffice.org/core/commit/1aae26d04a9eb219979a75e7d4c5fe6afb26d162 tdf#140404 Qt ignore "unchanged" clipboard events It will be available in 7.1.3. The patch should be included in the daily builds available at https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: https://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.