[vbox-dev] Close out Shared Clipboard race

[Andrew Caldwell]

Folks,

I noticed that copying from the omnibar in Google Chrome in a linux guest (Ubuntu or Centos) didn’t allow pasting into the host, despite (a) pasting in the guest working fine, and (b) copying from elsewhere in the guest (including from the body of Google Chrome pages)  works fine and allows pasting in the host.

To cut a long-ish story short, the problem boils down to “Google Chrome grabs the clipboard twice when you copy from the omnibar”, which is fine from their end (if a little weird) but VBoxClient doesn’t handle this correctly (see attached xtrace output with inline comments) since it calls into `XtGetSelectionValue` twice before handling the first answer, and `XtGetSelectionValue` doesn’t appear to be re-entrant so it ends up reporting that there are no allowed formats for the clipboard when the second callback fires.

Back in VBox < 5.2, there was some code to prevent this re-entrancy, but it was `ifndef`’d out in 5.2 and has been deleted completely in the recent changes to the Shared Clipboard, but it seems that this defensive code is still needed.  I’ve attached a patch to re-add the logic, which I hereby release under the MIT license.

Thanks,

A
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.virtualbox.org/pipermail/vbox-dev/attachments/20191126/8d9e63cb/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: VBoxClient-xtrace.log
Type: application/octet-stream
Size: 3899 bytes
Desc: VBoxClient-xtrace.log
URL: <http://www.virtualbox.org/pipermail/vbox-dev/attachments/20191126/8d9e63cb/attachment.obj>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: shared-clipboard-race.patch
Type: application/octet-stream
Size: 2216 bytes
Desc: shared-clipboard-race.patch
URL: <http://www.virtualbox.org/pipermail/vbox-dev/attachments/20191126/8d9e63cb/attachment-0001.obj>