Serious flaw in Cygwin X clipboard integration prevents paste from X to Windows apps

[Stahlman Brett]

Recently, I built a Cygwin X-enabled Vim from the Unix sources on my
Windows machine.  Everything seemed to work well until I attempted to
use the clipboard.  The first attempt worked, but subsequent attempts to
copy text in Vim and paste to a native Windows application failed. (The
original text was pasted each time.)

I looked into the issue, and actually wrote a patch for Unix Vim that
allows me to use the clipboard normally for pasting to native Win
applications. However, Bram Moolenaar of Vim insists (and I have come to
agree) that the problem is not with Vim but with the Cygwin X
implementation. Here's the problem as I understand it...

When an X app such as Vim wants to obtain selection ownership, it calls
a function such as XtOwnSelection (or the analogous toolkit-specific
wrapper). Cygwin X processes this request by opening the Windows
clipboard and calling SetClipboardData with a NULL data pointer,
signifying that Windows should send a WM_RENDERFORMAT message when
selection data is required for pasting into a native Windows
application. This works fine for the first selection. The problem occurs
when the user of the X app returns to the X app and changes the
selection. In general, the X app will not make another call to
XtOwnSelection (or the analogous function) because it already owns the
selection and assumes it will communicate the changed data to X only
when its callback function is called; i.e., when the selection is
requested by another app. Unfortunately, the callback will not be called
upon subsequent paste attempts for the following reason: Windows sends
the WM_RENDERFORMAT message to Cygwin X's xwinclip window if and only if
it believes the data it received in response to the last WM_RENDERFORMAT
message is no longer valid. From Windows' standpoint, if there have been
no intervening calls to OpenClipboard / SetClipboardData, the clipboard
is unchanged, and there's no reason to send another WM_RENDERFORMAT
message to the clipboard owner (xwinclip)! Thus, once a given X app owns
the selection, subsequent paste operations into a native Windows
application will always result in a paste of the initial selection made
in the X app! The data pasted into Windows apps will not change until
the selection owner changes.

The patch I implemented for Vim worked by forcing a change of selection
owner every time the selection within Vim changed. The solution was a
bit messy, as it required ignoring the "lose selection" callback, and in
the case of GTK, required processing X events between the call to
"disown" and "own" selection. Also, this solution is inefficient, as
multiple messages (e.g., WM_DESTROYCLIPBOARD, WM_DRAWCLIPBOARD) result
from every change of selection, and the selection may change rapidly
when, for example, you're selecting text with the mouse. Bram's other
argument against expecting X applications to implement workarounds such
as this is that it's not supposed to be necessary. There is no
requirement that an X app make a call into X every time the selection
changes. His suggestion (if I understood it correctly), which I believe
is very feasible, is to have XWin re-call SetClipboardData with a NULL
data pointer after processing each and every WM_RENDERFORMAT message.
This would effectively invalidate the data in the clipboard after each
time it was requested, forcing Windows to request it from xwinclip every
time the user of a Windows app performs a paste. Is there any reason why
this solution is not feasible? Have I misunderstood something about the
nature of the problem?

Thanks,
	Brett Stahlman


..........................................................
Mit freundlichem Gruß / Kind regards
Brett Stahlman
Senior Software Engineer
Siemens VDO Automotive AG
SV C BC
100 Electronics Blvd #240001
Huntsville, AL 35824-6401
The United States of America
Tel. 001.256.464.2227
Fax 001.256.464.2786
E-Mail: brett.stahlman@siemens.com
Internet: http://www.siemensvdo.com
 

--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Problem reports:       http://cygwin.com/problems.html
Documentation:         http://x.cygwin.com/docs/
FAQ:                   http://x.cygwin.com/docs/faq/