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

["Stahlman Family" <brettstahlman at comcast dot net>]

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.

Now that I know what Exceed is, I believe I understand better what you
propose. However, I see some problems with basing Windows clipboard
calls upon window "focus." Specifically, clipboard ownership should
change only in response to a copy in Windows or a selection change or
copy in an X app. Consider the following scenario: you copy some text
in an X app, then go to a Windows app to paste. After pasting, you copy
some text in the Windows app. At this point, the Windows app should own
the clipboard and the X app should receive a "lose selection" callback.
(I believe this is what happens already in Cygwin X.) If you then return
focus to the X app, you would not want the X server to reassert
ownership of the clipboard, as that would cause the data just copied in
the Windows app to be lost, data that you might have copied for the
purpose of pasting into the X app!

The fix originally proposed by Bram Moolenaar, which I outlined in my
initial post, is a bit different. Calling the Windows clipboard function
SetClipboardData with a NULL data pointer is conceptually like saying to
Windows: "I (xwinclip) own the clipboard. When you need data for pasting
into a Windows application, send me a WM_RENDERFORMAT message and I'll
give you the data." When do we want Windows to send us this request for
data? Well, every time a Windows app user attempts to paste; i.e., one
WM_RENDERFORMAT message for every paste operation. One way to achieve
this is to make the SetClipboardData call described above every time we
process the WM_RENDERFORMAT message in response to a paste. It's a
fairly simple solution unless I'm overlooking something...

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

I thought of this. I've never built XWin from source, but I did look at
the source, and I believe I have a good idea where the fix is needed. I
don't believe the fix itself need be extensive. I will try to look into
it as I get time over the next few days...

Thanks,
Brett Stahlman

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



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