Bidirectional clipboard on Arch host, Windows guest is unreliable

[enmes]

Hardware: i7-8565U (2019 X1 Carbon) with 16GB RAM, Windows VM has 8GB. DE is Gnome 45.1.
Virtualbox was installed with:

Code: Select all

sudo pacman -S virtualbox virtualbox-guest-iso virtualbox-host-modules-arch

Version 7.0.12 r159484

I'm a heavy user of the bidirectional clipboard, which is deeply integrated into my visual workflow. On both Wayland and Xorg, the clipboard is inconsistent: often, something will copy to clipboard (in host or in guest) and not be recognised when attempting to paste in the guest/host. Trying to copy something from the VM (in Adobe Acrobat, MS Word, or most often MemoQ, which is translation software) to the host (generally Firefox) will often cause FF to hang for a few minutes. When it recovers, the host clipboard will be empty.
However, trying again a few minutes later, I'm sometimes able to paste from host to guest with no issue. This becomes less likely the longer it has been since rebooting.

The problems are so inconsistent that I'm having a hard time knowing where to begin troubleshooting. What should be my next move?

[scottgus1]

There's some discussion of the clipboard problems here: viewtopic.php?t=109369

Especially the possibility of COM/API-based clipboarding which Virtualbox doesn't support yet.

Does the copy/pasting work when you use a web browser inside the VM? Does the copy/pasting work when you paste to an intermediary Notepad document in the VM , then copy/paste from Notepad to the host?

[enmes]

Does the copy/pasting work when you use a web browser inside the VM? Does the copy/pasting work when you paste to an intermediary Notepad document in the VM , then copy/paste from Notepad to the host?

Copy/paste works without issue within the VM. The intermediary Notepad method works, except when I try to do it immediately after direct guest app --> host app copy/paste has failed.

What I should emphasise here, though, is that copy/paste from e.g. guest MemoQ to host Firefox often does work, it's just very unreliable. It always works without issue when the host and guest have just booted. The problems only arise after copy-pasting a number of times (around five, but it's not consistent in that)

[scottgus1]

Interesting. Please try to get a log where the copy/paste from VM direct to host works, then where it fails. Please note the wall clock time when the VM starts, and the wall clock times when each copy/paste is tried, and whether each copy/paste works or not.

Start the VM from full normal shutdown, not save-state. Compile the information above, then shut down the VM from within the VM's OS if possible. If not possible, close the Virtualbox window for the VM with the Power Off option set.

Right-click the VM in the main Virtualbox window's VM list, choose Show in Explorer/Finder/File Manager. In the "Logs" subfolder, zip the VM's "vbox.log", and post the zip file, using the forum's Attachments tab. (Configure your host OS to show all extensions so you can find the "vbox.log", not "vbox.log.1", etc.)

[enmes]

VBox.zip

(24.39 KiB) Downloaded 16 times

Here you go:


17:16 - Adobe Acrobat in Win guest to Firefox in Linux host - succeeded
17:16 - Adobe Acrobat in Win guest to Firefox in Linux host - succeeded
17:18 - Adobe Acrobat in Win guest to Firefox in Linux host - failed (FF hangs v briedly when righ-clicking in address bar)
17:19 - Adobe Acrobat: "There was an error while copying to the Clipboard. An internal error occured." (this error message had not previously appeared).
17:20 - Acrobat in Win guest to Firefox in Win guest - succeeded
17:21 - VM suddenly closes entirely, without warning or error message

17:22 - VM restarted
17:22 - Adobe Acrobat in Win guest to Firefox in Linux host - failed (FF hangs v briefly when right-clicking in address bar)
17:23 - FF in Linux host to FF in Win guest - succeeded
17:24 - Adobe Acrobat in Win guest to Firefox in Linux host - succeeded
17:26 - Adobe Acrobat in Win guest to Firefox in Linux host - succeeded
17:33 - Adobe Acrobat in Win guest to Firefox in Linux host - succeeded
17:45 - Adobe Acrobat in Win guest to Firefox in Linux host - succeeded
17:46 - Adobe Acrobat in Win guest to Firefox in Linux host - succeeded
17:47 - Adobe Acrobat in Win guest to Firefox in Linux host - failed (Firefox hangs and showed Force Quit/Wait warning; I used Ctrl+V this time, had right-clicked previously)
17:46 - Adobe Acrobat in Win guest to Firefox in Linux host - failed (right-click again) same Acrobat warning appeared again in Win guest
17:50 - Adobe Acrobat in Win guest to Firefox in Win guest - succeeded
17:50 - Adobe Acrobat in Win guest to Firefox in Linux host - failed
17:50 - Adobe Acrobat in Win guest to Firefox in Linux host - failed; after a few seconds, same Acrobat error message appears in Win guest

[fth0]

FWIW, I've seen this issue being reported on the VirtualBox forums and in the VirtualBox Bugtracker several times, for different VirtualBox 7.0.x versions, but no solution yet. Most of the time (and also in your case), when the paste action is triggered on the host, the host asks the guest for the contents of the clipboard and runs into a timeout.

Do you think that the time between the copy action and the paste action plays a role?

[enmes]

Do you think that the time between the copy action and the paste action plays a role?

I paste immediately after copying (into dictionary or machine translation websites), so I assume not. In use, it *feels like* some kind of clipboard cache gets overtrained by frequent use between the OSs, but that's pure speculation, I have no tangible evidence for it (beyond the fact that it succeeds a few times, then fails)

[FranceBB]

FWIW, I've seen this issue being reported on the VirtualBox forums and in the VirtualBox Bugtracker several times, for different VirtualBox 7.0.x versions, but no solution yet.

I know and it would make our day if it was actually solved, given that we've been living with this "annoyance" since at least October 2022 viewtopic.php?p=531641
I hope someone in the community will care enough to contribute to the code and improve the behavior... perhaps... one day... :')

What I should emphasise here, though, is that copy/paste from e.g. guest MemoQ to host Firefox often does work

Yep, also if you do it the other way round like from Firefox in the guest to Slack, Teams, Outlook etc in the host.
If you try with Chrome, however, the chances of it not working and freezing increase, however sometimes it works and I can't really figure out why.

it *feels like* some kind of clipboard cache gets overtrained by frequent use between the OSs, but that's pure speculation, I have no tangible evidence for it (beyond the fact that it succeeds a few times, then fails)

I know the feeling 'cause I experience the very same thing: I copy-paste and wonder "will it work? will it stop working?" every time.
I don't know why but when the copy-paste stops working, I have to reboot the guest to make it work again.

[fth0]

I hope someone in the community will care enough to contribute to the code and improve the behavior... perhaps... one day... :')

From my POV, we as a community (and that includes you as well as me and all the others) are still in the phase of analyzing and understanding the behavior. If we find out "detailed enough" properties of the issue, so that a VirtualBox developer can solve it without needing too much time themselves, we could defeat the (probably relatively low) priority of the issue. Regarding some details:

1. Timing: The issue being logged as a timeout issue naturally leads to questions about timing, but it might be unrelated to timing nonetheless. Timing can play a role in different ways: Intervals between different actions can be too small or too large, for example.

2. Clipboard strategies: Windows and Linux have different clipboard strategies: While on a Windows clipboard the data is typically copied when the copy action and the paste action are triggered, on a Linux clipboard the data is typically only copied when the paste action is triggered. This is already an oversimplification, and I didn't even mention VirtualBox or Remote Desktops (I don't want to write an essay here ).

A general strategy would be to eliminate as many variables as possible from the reproduction of the issue ...