Strange clipboard share in VirtualBox 6 (#18285)

[Kweo]

A bit more info.

The issue with flameshot occurs in a very specific use case when using this patch : github [dot] com /demivi/PKGBUILDs/blob/master/flameshot/clipboard.patch. It does not work when doing "flameshot gui -c" and hitting CTRL-C to save the screenshot to clipboard. Like with the Chrome address bar, this used to work fine in VB 5 and the screenshot is correctly set on the host.

One thing that might interest you more is that the bug also occurs (at least on Arch) with KeePass (original mono version) when its "xsel" optional dependency is not installed. The reason for it being optional as stated for the Arch package is: "clipboard operations in order to work around Mono clipboard bugs".

[wq]

VirtualBox version: Version 6.0.4 r128413 (Qt5.9.5)
Host: xubuntu 18.04
Guest: windows 7

1. I can copy plain text from Host to Guest or from Guest to Host without any problem
2. When I try to copy page u-r-l from Google Chrome location and paste it into Guest's notepad, it does not work, context menu of the notepad shows that nothing is copied
3. I try to do the same operation using Firefox, and it worked!

What's going wrong? Google Chrome? or Clipboard share? is there any way to fix it?

[socratis]

It's Chrome, I've heard other reports about it. Try it with Firefox. Don't use Google, they're evil

[RVT]

Very interesting stumbling on this thread. I just started googling to figure out what the heck broke on my VirtualBox installation because of this same issue.

I first noticed it in Chrome as well, trying to copy links from Chrome to a windows 10 guest notepad.

Running Fedora 28 on Linux, with Win 10 guest.

Copy and paste from Firefox did work ok.

If I can provide data, great. I'm not an expert but have been at least a VirtualBox user for a few years.

[Aren Cambre]

Here's a bug report for this problem: https://www.virtualbox.org/ticket/18285

[socratis]

@Aren Cambre
Excuse me, but... are you kidding me? The ticket number is in the title of the thread (the #18285 part), and the ticket description and link are in the first post! That same first post, which if you take a closer look at its end, it has the following entry:

---

Last edited by socratis on 2019-01-08, 20:13, edited 2 times in total.
Reason: Added ticket related information.

You should be reading the threads from the beginning next time...

[certmic]

I have the same problem, but only with Chrome. I tried with Firefox and it works.

[agilis]

I am experiencing the same issue.

My specific issue in detail: Cannot paste a URL copied from Google Chrome's address bar running on a Linux Guest to a Windows 10 Host.

Google Chrome: Version 72.0.3626.81 (Official Build) (64-bit)

[Edu_Web]

I have the same issue.

I was running the last 5.x version of VirtualBox in Ubuntu 16.04 host and Win 7 Guest. Bi-Directional copy and paste was working great.
After upgrading to Ubuntu 18.04 and VirtualBox 6 with the same Win 7 machine I got this issue. (I upgraded virtualbox guest aditions to this machine.)

I can't copy from Chome address bar to guest Win 7. (If I paste the address in another host's aplication or terminal and re-copy it again I'm able to paste it in Win 7 guest.

With Firefox os other applications copy and past works great.

As another test, when typing this repply I copied the prase above and I'm able to past into Win 7 guest. It looks like the issue happens only from chrome address bar.

[socratis]

Right, we've already established that. The question is: has anyone complained to Chrome about it? Do you have a reference ticket that we can watch, like we have here?

[agilis]

Right, we've already established that. The question is: has anyone complained to Chrome about it? Do you have a reference ticket that we can watch, like we have here?

Perhaps I am misunderstanding something but why would anyone complain to Google about this issue? It seems to be clearly an issue with Version 6.x of VirtualBox. Because as others, like myself, have pointed out, the issue is not present on VirtualBox 5.x.

[socratis]

Perhaps I am misunderstanding something but why would anyone complain to Google about this issue?

Because if you read the thread from the beginning the changes were instituted due to a crash. What Chrome does however is to put the contents to the clipboard different than anyone else. For example, compare the contents after a Firefox/Gedit/Terminal copy:

$ xclip -o -t TARGETS
TIMESTAMP
TARGETS
MULTIPLE
UTF8_STRING
STRING
TEXT
COMPOUND_TEXT
text/plain;charset=utf-8
text/plain

and after a Chrome copy of the address bar:

$ xclip -o -t TARGETS
TIMESTAMP
TARGETS
MULTIPLE
UTF8_STRING
STRING
TEXT
SAVE_TARGETS
text/plain

So, the Chrome "copy" doesn't store the contents as a "text/plain;charset=utf-8". That's where talking to Chrome as well might help alleviate the problem from the other side...

[Sarke]

Doesn't that just mean that Chrome saves the text as non-utf8 text? I.e. just plain ASCII.

Chrome can't be the only program that uses this.

Shouldn't VirtualBox 6 be able to read that? After all, VirtualBox 5 could.

[socratis]

Chrome can't be the only program that uses this.

From the (rather limited) tests that I did, Chrome is the only one doing this. What did you find during your testing?

After all, VirtualBox 5 could.

We've gone through that more times that I care to explain anymore to people that don't read the thread from the beginning.

(Hint: VirtualBox was crashing)

[Sarke]

I did read the thread, I started it. I don't think it's related to the crash issue described in https://www.virtualbox.org/ticket/15782. I'm also not using MacOS but using Linux on both host and guest, and I don't see any indication of the of VBoxClient failing and or having to be restarted.

If 15782 was the cause, then using 5.2 versions after that fix should behave the same as 6.0, right? But it doesn't.

I don't think it's related to 15960 either as that is text/html, which this isn't. text/html works fine for me in both versions.


Here's some logs I took comparing the two:

Working in 5.2 copying from host Chrome omnibox to guest:

Code: Select all

00:01:21.048169 void clipQueryX11CBFormats(CLIPBACKEND*): requesting the targets that the X11 clipboard offers
00:01:21.048169 void clipQueryX11CBFormats(CLIPBACKEND*): requesting the targets that the X11 clipboard offers
00:01:21.048169 clipConvertX11Targets: pValue=00007f6d40001120, *pcLen=9, *atomType=4
00:01:21.048169 clipUpdateX11Targets: called
00:01:21.048169 void clipQueryX11CBFormats(CLIPBACKEND*): requesting the targets that the X11 clipboard offers
00:01:21.048169 clipConvertX11Targets: pValue=00007f6d40001120, *pcLen=9, *atomType=4
00:01:21.048169 clipUpdateX11Targets: called
00:01:21.048169 clipReportFormatsToVBox: clipReportFormatsToVBox format: 5
00:01:21.048169 clipReportFormatsToVBox: clipReportFormatsToVBox txt: 1, bitm: 0, html:7, u32VBoxFormats: 5
00:01:21.048169 ClipReportX11Formats: called.  pCtx=00007f6cc4001d40, u32Formats=05
00:01:21.048169 vboxSvcClipboardReportMsg: Formats 05
00:01:21.048169 vboxSvcClipboardReturnMsg: Formats 05
00:01:21.048169 vboxSvcClipboardReportMsg: CallComplete
00:01:21.048169 svcCall: u32ClientID = 14, fn = 1, cParms = 2, pparms = -469666832
00:01:21.048169 svcCall: VBOX_SHARED_CLIPBOARD_FN_GET_HOST_MSG
00:01:21.048169 vboxSvcClipboardReturnMsg: no message
00:01:21.048169 svcCall: async.
00:01:21.048169 svcCall: rc = VINF_SUCCESS
00:01:21.053339 svcCall: u32ClientID = 14, fn = 3, cParms = 3, pparms = -837346832
00:01:21.053360 svcCall: VBOX_SHARED_CLIPBOARD_FN_READ_DATA
00:01:21.053365 vboxClipboardReadData: pClient=00007f6cc0005f90, u32Format=01, pv=00007f6cce5589b0, cb=1024, pcbActual=00007f6d1c098dacclipQueueToEventThread: proc=00007f6cd69a1060, client_data=00007f6cc4020900
00:01:21.053380 vboxClipboardReadData: returning VINF_HGCM_ASYNC_EXECUTE
00:01:21.053390 svcCall: rc = VINF_HGCM_ASYNC_EXECUTE
00:01:21.053402 vboxClipboardReadX11Worker: pReq->mFormat = 01
00:01:21.053414 vboxClipboardReadX11Worker: status VINF_SUCCESS
00:01:21.053428 clipDrainWakeupPipe: called
00:01:21.053639 clipConvertX11CB: pReq->mFormat=01, pReq->mTextFormat=1, pReq->mBitmapFormat=0, pReq->mHtmlFormat=0, pReq->mCtx=00007f6cc4001e10
00:01:21.053649 clipUtf8ToWinTxt: pcSrc=00007f6d40001590, cbSrc=55, ppwszDest=00007f6ca715a828
00:01:21.053654 clipUtf16ToWinTxt: pwcSrc=00007f6d40001700, cwcSrc=55, ppwszDest=00007f6ca715a828
00:01:21.053658 clipUtf16ToWinTxt: converted string is https://forums.virtualbox.org/viewtopic.php?f=7&t=91093
00:01:21.053662 clipUtf16ToWinTxt: returning VINF_SUCCESS
00:01:21.053664 clipUtf16ToWinTxt: *pcbDest=112
00:01:21.053667 clipUtf8ToWinTxt: Returning VINF_SUCCESS
00:01:21.053670 clipUtf8ToWinTxt: *pcbDest=112
00:01:21.053684 clipConvertX11CB: rc=VINF_SUCCESS

Not working in 6.0 copying from host Chrome omnibox to guest:

Code: Select all

00:01:15.718778 void clipQueryX11CBFormats(CLIPBACKEND*): requesting the targets that the X11 clipboard offers
00:01:15.719472 void clipQueryX11CBFormats(CLIPBACKEND*): requesting the targets that the X11 clipboard offers
00:01:15.721072 clipConvertX11Targets: pValue=00007f92b4001100, *pcLen=9, *atomType=4
00:01:15.721099 clipUpdateX11Targets: called
00:01:15.721104 clipReportFormatsToVBox: clipReportFormatsToVBox format: 5
00:01:15.721108 clipReportFormatsToVBox: clipReportFormatsToVBox txt: 1, bitm: 0, html:7, u32VBoxFormats: 5
00:01:15.721113 ClipReportX11Formats: called.  pCtx=00007f9228001d40, u32Formats=05
00:01:15.721117 vboxSvcClipboardReportMsg: Formats 05
00:01:15.721121 vboxSvcClipboardReturnMsg: Formats 05
00:01:15.721125 vboxSvcClipboardReportMsg: CallComplete
00:01:15.721331 svcCall: u32ClientID = 12, fn = 1, cParms = 2, pparms = 1492835168
00:01:15.721345 svcCall: VBOX_SHARED_CLIPBOARD_FN_GET_HOST_MSG
00:01:15.721349 vboxSvcClipboardReturnMsg: no message
00:01:15.721352 svcCall: async.
00:01:15.721355 svcCall: rc = VINF_SUCCESS
00:01:15.721361 clipConvertX11Targets: pValue=0000000000000000, *pcLen=0, *atomType=0
00:01:15.721371 clipConvertX11Targets: reporting empty targets (none reported or allocation failure).
00:01:15.721375 clipUpdateX11Targets: called
00:01:15.721379 clipReportFormatsToVBox: clipReportFormatsToVBox format: 0
00:01:15.721382 clipReportFormatsToVBox: clipReportFormatsToVBox txt: 0, bitm: 0, html:0, u32VBoxFormats: 0
00:01:15.721387 ClipReportX11Formats: called.  pCtx=00007f9228001d40, u32Formats=00
00:01:15.721391 vboxSvcClipboardReportMsg: Formats 00
00:01:15.721395 vboxSvcClipboardReturnMsg: Formats 00
00:01:15.721398 vboxSvcClipboardReportMsg: CallComplete
00:01:15.722875 svcCall: u32ClientID = 12, fn = 1, cParms = 2, pparms = 1492835168
00:01:15.722892 svcCall: VBOX_SHARED_CLIPBOARD_FN_GET_HOST_MSG
00:01:15.722898 vboxSvcClipboardReturnMsg: no message
00:01:15.722902 svcCall: async.
00:01:15.722906 svcCall: rc = VINF_SUCCESS

Obviously Chrome is doing something funky, but I don't think it's setting a strange format but a race condition caused by Chrome setting the clipboard more than once in a short span, as I suggested earlier. This would be confirmed by the logs showing more than one "requesting the targets that the X11 clipboard offers" event.

Chrome uses some handlers, among other things to prepend the protocol when copying a url from the omnibox, which explains the extra events.

Also, the fact that all of these events are logged at 00:01:21.048169 (version 5.2 log above) suggests that VirtualBox 5.2 was able to handle these events properly and still end up with a valid clipboard. In 6.0, however, these are not logged with the same timestamp but has a small delay, and that could explain why the second "clipConvertX11Targets" event shows "pValue=0000000000000000, *pcLen=0, *atomType=0" indicating an empty clipboard, while just 289 microseconds earlier it had a valid clipboard "clipConvertX11Targets: pValue=00007f92b4001100, *pcLen=9, *atomType=4".

So I strongly feel this is VirtualBox 6.0 having a problem handling quick replacement of clipboard content. I suspect this will affect not only Chrome, but any clipboard manager that auto-transforms the content.