Bug 5735

Created attachment 4479 [details] [review]
Experimental patch to fix the problem

Here's an experimental patch. It appears to fix the issue Stahlman Brett was
having with unix gvim running on Windows.

I have used the patch in Xming and, so far, it looks sound and fixes the bug.
(Xming shares the same code as Cygwin/X)

Colin Harrison

Sorry about the "endian" bug in Brett's name
Should be "Brett Stahlman" credited for reporting and fixing this bug.

Thanks
Harrison Colin

I am finding this bug very annoying, as I use gvim with cygwin.
Why isn't the patch checked in. There isn't any comment on the patch also.

-MMJ

Can someone explain why the patch does this....

 
-#ifdef HAVE_XWIN_CONFIG_H
-#include <xwin-config.h>
-#endif
-#include <sys/types.h>
-#include <sys/time.h>

???

Created attachment 6592 [details] [review]
Revised patch

Revised patch removes that and 3 unneccesary ErrorF traps.

Applied. Thanks.

Reopening.  This patch solves the problem it addresses, but creates a new one.

Clipboard monitoring applications (such as clipbrd.exe) notice the delayed reset of the clipboard done in WM_USER_PASTE_COMPLETE message handler, and request the clipboard contents to be rendered again, leading to an infinite loop.

A bit more analysis is needed of why working with the selection in gvim doesn't always cause the windows clipboard contents to get updated.

Has this been addressed?

I still use the patch for this problem in Xming..but only under a special 'quirk' option -clipboard2. I have had no user reports since providing this and cannot reproduce the problem anyway. So the bug has not gone away..it's just got old!

The code is better without the patch and should be reverted.

(In reply to comment #10)
> I still use the patch for this problem in Xming..but only under a special
> 'quirk' option -clipboard2. I have had no user reports since providing this and
> cannot reproduce the problem anyway. So the bug has not gone away..it's just
> got old!
> 
> The code is better without the patch and should be reverted.

I agree this patch is not the correct fix.  I've been reverting this patch in the Cygwin X server releases for a couple of years, so I've generated a patch to revert this and sent it for your review.

However, I can reproduce the original bug quite easily using gitk, copying the SHA-1 hash from that works the first time, but the windows clipboard does not get updated when a changed SHA-1 hash is copied.

Created attachment 56991 [details] [review]
Adjusted patch to clear Windows clipboard on loss of focus

Digging into why this is happening with gitk:

XWin only monitors for selection owner changing.  An application which already owns the selection can change it's idea of what's in the selection without us noticing.

For example, gitk (and probably all applications using Tk) only claim the selection when it moves between controls, so one can adjust the selection within a control without any notice.

It's pretty straightforward to adjust the previous fix so we only clear the Windows clipboard when an X Window loses focus, which is actually suggested in the email thread linked.

But this makes the assumption that whenever X gains focus, the selection will be adjusted. So is almost, but not quite right: If the selection isn't altered while we have the focus, then we've destroyed what was on the clipboard previously.

I did hope that we could use the selection TIMESTAMP to determine if it has been adjusted while an X window has focus, but that doesn't seem to be workable: Tk always returns 0 for the TIMESTAMP.

Another approach would be to act like xclipboard, and claim the selection every time we lose ownership, so that X applications have to claim it everytime they want to change it, so we get a selection ownership change notification everytime that happens.  This should be workable for CLIPBOARD, but is no good for PRIMARY, as taking ownership of PRIMARY causes the highlighting of the PRIMARY selection to disappear.

(In reply to comment #12) 
> XWin only monitors for selection owner changing.  An application which already
> owns the selection can change it's idea of what's in the selection without us
> noticing.

Note that this is only an issue with PRIMARY.  The ICCCM requires that ownership of CLIPBOARD is reasserted when it's contents change.
 
> It's pretty straightforward to adjust the previous fix so we only clear the
> Windows clipboard when an X Window loses focus, which is actually suggested in
> the email thread linked.
> 
> But this makes the assumption that whenever X gains focus, the selection will
> be adjusted. So is almost, but not quite right: If the selection isn't altered
> while we have the focus, then we've destroyed what was on the clipboard
> previously.

So, perhaps when X server loses focus, if ownership of PRIMARY hasn't changed since the last time we lost focus, we could request the contents of PRIMARY, and if it has changed, clear the Windows clipboard?  (This might interact badly with with changes to the CLIPBOARD selection as we wouldn't know when the contents of PRIMARY changed, so would always be assuming that PRIMARY changed last)

-- GitLab Migration Automatic Message --

This bug has been migrated to freedesktop.org's GitLab instance and has been closed from further activity.

You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.freedesktop.org/xorg/xserver/issues/197.