Opened 8 years ago
Closed 7 years ago
#15782 closed defect (fixed)
Shared Clipboard failing; Guest to Host -> fixed in 5.2 builds after Nov 10 2017
Reported by: | philip | Owned by: | |
---|---|---|---|
Component: | clipboard | Version: | VirtualBox 5.1.2 |
Keywords: | Cc: | ||
Guest type: | other | Host type: | Mac OS X |
Description
The "Guest to Host" shared clipboard functionality is failing for me with VirtualBox 5.1.2. I have an OS X 10.11.6 host, with an LUbuntu 16.04 guest. Both "Guest to Host" and "Bidirectional" settings behave as if only "Host to Guest" is allowed.
I had reported this during the Beta phase here: https://forums.virtualbox.org/viewtopic.php?f=15&t=78285
Note: It is possible to copy text on the guest, then paste into the guest (i.e., the guest's clipboard works fine within the guest itself) but contents do not make it to the shared clipboard. Also, the shared clipboard does work fine as "Host to Guest".
Change History (13)
comment:1 by , 8 years ago
comment:2 by , 8 years ago
I had this problem with 5.1.6 and thought it was solved on 5.1.8, but it appears that guest->host works for a while then stops. Host->guest and guest->guest works.
Restarting "/usr/bin/VBoxClient --clipboard" brings it back to life again, for a while.
I am running a Solaris 12 guest on MacOS X 10.11.6.
comment:3 by , 8 years ago
It may have something to do with copying rich text to the clipboard, it seems to break VBoxClient clipboard and it needs to be restarted. At least that's what I'm seeing in my setup, CentOS 7 guest, as soon as I copy some rich text to the clipboard (plain text is fine), host/guest copy/paste functionality is toast until I restart VBoxClient --clipboard.
comment:4 by , 8 years ago
It would be interesting to know if enabling extended logging in VBoxClient<1> produces any additional information (the original reporters please, not @tkvb, as you have already reported your issue elsewhere, and this could be different issues). And please attach a host log file (see ticket creation guidelines<2>).
comment:5 by , 8 years ago
I am experiencing the same as tkvb. The log isn't showing anything useful after a lot of copy-n-pasting, only:
Shared clipboard: Initializing X11 clipboard backend Shared clipboard: Starting shared clipboard thread
I do have vague memories of wondering why it seemingly failed after copying text from my browser, but not the terminal.
comment:6 by , 8 years ago
The aforementioned bug by tkvb is Bug #16242, which contains useful information related to this problem.
comment:7 by , 7 years ago
Host: macOS 10.12.6 (16G1036) Guest: lUbuntu 16.04.3 LTS (X.Org X Server 1.18.4) VB: 5.1.30 (same version for guest additions and extensions)
Copying plain text (from guest) works fine initially. However, copying rich text once breaks the clipboard mechanism (for rich or plain).
The logs:
Starting VirtualBox:
vboxClipboardConnect: Shared clipboard: Initializing X11 clipboard backend ClipStartX11: Shared clipboard: Starting shared clipboard thread vboxClipboardConnect: g_ctx.client=65 rc=VINF_SUCCESS vboxClipboardMain: Starting guest clipboard service
Copying plain text appends this (works):
void clipQueryX11CBFormats(CLIPBACKEND*): requesting the targets that the X11 clipboard offers clipConvertX11Targets: pValue=00007f2548000fe0, *pcLen=10, *atomType=4 clipUpdateX11Targets: called clipReportFormatsToVBox: clipReportFormatsToVBox format: 1 clipReportFormatsToVBox: clipReportFormatsToVBox txt: 1, bitm: 0, html:0, u32VBoxFormats: 1 ClipReportX11Formats: u32Formats=1 vboxClipboardMain: VBOX_SHARED_CLIPBOARD_HOST_MSG_READ_DATA fFormats=1 clipQueueToEventThread: proc=0000000000406bf0, client_data=0000000002068c00 ClipReportX11Formats: rc=VINF_SUCCESS processed host event rc = 0 vboxClipboardReadX11Worker: pReq->mFormat = 01 vboxClipboardReadX11Worker: status VINF_SUCCESS clipDrainWakeupPipe: called clipConvertX11CB: pReq->mFormat=01, pReq->mTextFormat=1, pReq->mBitmapFormat=0, pReq->mHtmlFormat=0, pReq->mCtx=00000000020454a0 clipUtf8ToWinTxt: pcSrc=00007f2548000f00, cbSrc=31, ppwszDest=00007f25520be838 clipUtf16ToWinTxt: pwcSrc=00007f2548000f90, cwcSrc=31, ppwszDest=00007f25520be838 clipUtf16ToWinTxt: converted string is I AM BEING COPIED FROM TERMINAL clipUtf16ToWinTxt: returning VINF_SUCCESS clipUtf16ToWinTxt: *pcbDest=64 clipUtf8ToWinTxt: Returning VINF_SUCCESS clipUtf8ToWinTxt: *pcbDest=64 vboxClipboardSendData: u32Format=1, pv=00007f25480012b0, cb=64 vboxClipboardSendData: rc=VINF_SUCCESS clipConvertX11CB: rc=VINF_SUCCESS
Copying rich text the first time appends this:
void clipQueryX11CBFormats(CLIPBACKEND*): requesting the targets that the X11 clipboard offers clipConvertX11Targets: pValue=00007f32440012b0, *pcLen=12, *atomType=4 clipUpdateX11Targets: called clipReportFormatsToVBox: clipReportFormatsToVBox format: 5 clipReportFormatsToVBox: clipReportFormatsToVBox txt: 1, bitm: 0, html:7, u32VBoxFormats: 5 ClipReportX11Formats: u32Formats=5 vboxClipboardMain: VBOX_SHARED_CLIPBOARD_HOST_MSG_READ_DATA fFormats=5 clipQueueToEventThread: proc=0000000000406bf0, client_data=0000000000be5ac0 ClipReportX11Formats: rc=VINF_SUCCESS processed host event rc = 0 vboxClipboardReadX11Worker: pReq->mFormat = 05 vboxClipboardSendData: u32Format=0, pv=0000000000000000, cb=0 vboxClipboardSendData: rc=VINF_SUCCESS vboxClipboardReadX11Worker: status VERR_NOT_IMPLEMENTED clipDrainWakeupPipe: called
Subsequent copies (rich or plain) appends this:
void clipQueryX11CBFormats(CLIPBACKEND*): requesting the targets that the X11 clipboard offers
comment:8 by , 7 years ago
It would be good if you could provide the whole log file as well, although of course your analysis is helpful. Perhaps you could actually add comment lines into the log file. Regarding the subsequent copies, is that the only text which gets appended?
comment:9 by , 7 years ago
Actually I was able to reproduce it by simulating what your Mac host sends on my Linux host.
comment:10 by , 7 years ago
I am uploading test builds<1> for the development branch (current 5.2) which I think should fix this. They should be available in half an hour or so. You should re-install the Guest Additions as well.
comment:11 by , 7 years ago
Thank you Michael, confirmed that it's fixed in the test builds! Woohoo!
Although it does not matter now, that was the entire log file... I simply split it up into chunks separated by action.
Again, thanks for tackling this bug :)
comment:12 by , 7 years ago
Summary: | Shared Clipboard failing; Guest to Host → Shared Clipboard failing; Guest to Host -> fixed in 5.2 builds after Nov 10 2017 |
---|
comment:13 by , 7 years ago
Resolution: | → fixed |
---|---|
Status: | new → closed |
I tested it with VirtualBox 5.1.3 build 110033 and with Ubuntu 12.04 (32-bit) and Mint 17 (64-bit). No problems observed. Clipboard copy/paste is working as it is supposed to, back and forth.