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

["Stahlman Brett" <brett dot stahlman at siemens dot com>]

> > 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?
> 
> I'm not very familiar with the details of how the clipboard handling is
> implemented in Cygwin/X (though I do know that there is a choice of the
> external xwinclip application and the internal -clipboard handling).  The
> way applications like Exceed seem to do it is by relinquishing clipboard
> ownership on losing focus, and reacquiring the clipboard on getting the
> focus.  Perhaps this approach will also work for Cygwin/X?
> 	Igor

It might work, but that would require all X applications to implement a
workaround for what appears to be a Cygwin X bug. This is the main
reason the Vim owner wouldn't include my patch, even though it fixes the
clipboard problem. I believe his reasoning is, "if the fault is Cygwin
X's, then so should be the remedy". While I agree in principle, I will,
of course, continue to use the patch until it's fixed in Cygwin.
Incidentally, you mentioned Exceed having had to come up with a
workaround as well. Is this problem known to the XWin developers? I
didn't see anything in the TODO, but I can't imagine that something like
this hasn't been reported by now.

Incidentally, the external xwinclip application is supposed to be
obsolete now, I think. I believe new development may be taking place
only on the integrated version, but I could be wrong.

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/