Re: Serious flaw in Cygwin X clipboard integration prevents pastefrom 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
>
> It might work, but that would require all X applications to implement a
> workaround for what appears to be a Cygwin X bug.

I think you misunderstood my point.  What I was saying was that the X
server relinquishes the clipboard upon *any* of the X applications on that
server losing focus to a Windows application, and then reacquires it
whenever the focus comes back to any X application on that display.

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

I agree with his reasoning.  This is a bug in Cygwin/X, and your analysis
may be helpful to the developers.  But what would be even more helpful is
a patch.  Would you be willing to build the XWin server and try out the
proposed fix at the server level?

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

I'm just observing this from the way Exceed works (messages, etc).  I
haven't seen Exceed source code, so this is conjecture at best.  But there
should be no reason it wouldn't work for Cygwin/X...

BTW, a workaround at the Exceed level would be equivalent to changing
XWin.exe appropriately, not the applications.

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

There were reports of problems with the integrated version that were
absent in xwinclip -- I'd guess both would be used for some time yet.
	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/