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

[Igor Peshansky <pechtcha at cs dot nyu dot edu>]

On Wed, 18 Jan 2006, Stahlman Brett wrote:

> 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
-- 
				http://cs.nyu.edu/~pechtcha/
      |\      _,,,---,,_	    pechtcha@cs.nyu.edu | igor@watson.ibm.com
ZZZzz /,`.-'`'    -.  ;-;;,_		Igor Peshansky, Ph.D. (name changed!)
     |,4-  ) )-,_. ,\ (  `'-'		old name: Igor Pechtchanski
    '---''(_/--'  `-'\_) fL	a.k.a JaguaR-R-R-r-r-r-.-.-.  Meow!

"Las! je suis sot... -Mais non, tu ne l'es pas, puisque tu t'en rends compte."
"But no -- you are no fool; you call yourself a fool, there's proof enough in
that!" -- Rostand, "Cyrano de Bergerac"

--
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/