Discussion:
test case for clipboard hang?
(too old to reply)
Lev Bishop
2004-03-25 21:06:49 UTC
Permalink
Harold: you wanted a test case for the clipboard hang. I can do it this
way, using only xterm and notepad:

1) open xterm and notepad
2) type some stuff in the xterm
3) left click and drag to select text in the xterm (it gets highlighted) -
let go of the mouse, and the text stays highlighted in reverse video.
4) single left click somewhere else in the xterm - the reverse video
highlighting of the selection is removed
5) bring the focus to notepad and ^V to paste: it hangs for 3secs and
doesn't paste (previously it would have hung completely).

Note 1: if in between steps 3 and 4 you paste into notepad, it works, and
even if you continue to step 5 it still works, you have to do it in that
order.

Note 2: Even after step 5 you can still paste X->X, ie middle-click in a
different xterm and the paste goes through. (Maybe now it gets it from the
CUT_BUFFER0 instead of from PRIMARY, the xterm manual states that
selecting text puts it in both PRIMARY and in CUT_BUFFER0 -- presumably
step 4 removes PRIMARY but does nothing to CUT_BUFFER0).

Lev
Harold L Hunt II
2004-03-25 21:36:29 UTC
Permalink
Lev,
Post by Lev Bishop
Harold: you wanted a test case for the clipboard hang. I can do it this
1) open xterm and notepad
2) type some stuff in the xterm
3) left click and drag to select text in the xterm (it gets highlighted) -
let go of the mouse, and the text stays highlighted in reverse video.
4) single left click somewhere else in the xterm - the reverse video
highlighting of the selection is removed
5) bring the focus to notepad and ^V to paste: it hangs for 3secs and
doesn't paste (previously it would have hung completely).
Note 1: if in between steps 3 and 4 you paste into notepad, it works, and
even if you continue to step 5 it still works, you have to do it in that
order.
Note 2: Even after step 5 you can still paste X->X, ie middle-click in a
different xterm and the paste goes through. (Maybe now it gets it from the
CUT_BUFFER0 instead of from PRIMARY, the xterm manual states that
selecting text puts it in both PRIMARY and in CUT_BUFFER0 -- presumably
step 4 removes PRIMARY but does nothing to CUT_BUFFER0).
I can't reproduce this at all.

The behavior I get is that in step 5 if you press Ctrl+V nothing happens
(no delay, no pasting) and if you right click the context menu entry for
"Paste" is greyed out (since X released ownership of the selection).

So, what version of Windows are you running and are you doing anything
with multiple languages or locales?

Harold
Jack Tanner
2004-03-25 23:49:47 UTC
Permalink
Post by Harold L Hunt II
I can't reproduce this at all.
The behavior I get is that in step 5 if you press Ctrl+V nothing happens
(no delay, no pasting) and if you right click the context menu entry for
"Paste" is greyed out (since X released ownership of the selection).
I confirm that I can reproduce the bug using the procedure Lev outlined.
If you right-click the context menu, Paste is enabled.

Suggestion: Harold, if you think it'll help, feel free to post an
instrumented build that writes to a log file things that may help to
track down this bug. I volunteer to run this build, and send in the log
whenever a crash occurs.
Lev Bishop
2004-03-25 23:06:28 UTC
Permalink
Post by Harold L Hunt II
I can't reproduce this at all.
The behavior I get is that in step 5 if you press Ctrl+V nothing happens
(no delay, no pasting) and if you right click the context menu entry for
"Paste" is greyed out (since X released ownership of the selection).
So, what version of Windows are you running and are you doing anything
with multiple languages or locales?
Microsoft Windows XP
Home Edition
Version 5.1 (Build 2600.xpsp2.030422-1633: Service Pack 1)

As for languages & locales, not aware that I'm doing anything strange. How
can I tell for sure? I have got the "Standards and Formats", under the
"regional options" tab of the "regional and language options" control
panel applet set to english(UK) forcurrency, date,... formatting, but
that's all that I know of.

Any other info you'd like?

Lev
Harold L Hunt II
2004-03-25 23:11:18 UTC
Permalink
Post by Lev Bishop
Post by Harold L Hunt II
I can't reproduce this at all.
The behavior I get is that in step 5 if you press Ctrl+V nothing happens
(no delay, no pasting) and if you right click the context menu entry for
"Paste" is greyed out (since X released ownership of the selection).
So, what version of Windows are you running and are you doing anything
with multiple languages or locales?
Microsoft Windows XP
Home Edition
Version 5.1 (Build 2600.xpsp2.030422-1633: Service Pack 1)
As for languages & locales, not aware that I'm doing anything strange. How
can I tell for sure? I have got the "Standards and Formats", under the
"regional options" tab of the "regional and language options" control
panel applet set to english(UK) forcurrency, date,... formatting, but
that's all that I know of.
Hmm... nothing weird about any of that. Please tell me you have
rebooted since installing the new version... I want to make sure that
there is no funkiness left over from the previous XWin.exe crashing
and/or screwing up the clipboard viewer chain.

Harold
Lev Bishop
2004-03-26 01:10:43 UTC
Permalink
Harold: Yes, I did reboot. I've rebooted again and found a variety of
peculiar clipboard related behaviours that are somewhat tricky to
reproduce reliably (just using xterm and notepad here). Simply doing the
procedure I descibed before, immediately after a reboot, doesn't work the
way I described, it works the way you described. However, after the
reboot, after a bit of playing around with clipboard stuff during which
time various odd things happen, it seems to settle down into a state where
the previous procedure works the way I described. Some of the things I've
observed before it settles down are: not being able to paste windows->X;
xterm hanging for a few seconds, apparently until I select text in
windows and copy to clipboard in windows; xterm not responding to
pastes for quite a while but then later doing all the pastes it
should have done earlier; etc. I haven't been able to reproduce any of
these behaviours in a reliable way.

However, I've repeated the following procedure 3 times and it worked the
same each time -- probably not a minimal test case but it shows the
problem. I have to follow the steps precisely in order, though:

1) Reboot
2) start a fresh xwin, xterm, notepad, and put some text in the xterm and
notepad
3) select, ^C copy from notepad, middle-click in xterm. it pastes
successfully
4) select in xterm, leave the text reverse-videoed
5) ^V paste into notepad (successfully)
6) drop the selection in xterm (by left clicking somewhere)
7) ^V paste into notepad (successfully, even though the selection is
dropped)
8) select a different piece of text in xterm.
9) drop the selection in xterm
10) ^V paste into notepad: it hangs for a few seconds and doesn't paste.
(The paste menu option is NOT greyed out at this point).

I hope this is now reproducible for you. Let me know if there's any other
info you need, or anything you want me to try doing.

Lev
Harold L Hunt II
2004-03-26 18:18:54 UTC
Permalink
Lev,
Post by Lev Bishop
However, I've repeated the following procedure 3 times and it worked the
same each time -- probably not a minimal test case but it shows the
1) Reboot
2) start a fresh xwin, xterm, notepad, and put some text in the xterm and
notepad
3) select, ^C copy from notepad, middle-click in xterm. it pastes
successfully
4) select in xterm, leave the text reverse-videoed
5) ^V paste into notepad (successfully)
6) drop the selection in xterm (by left clicking somewhere)
7) ^V paste into notepad (successfully, even though the selection is
dropped)
8) select a different piece of text in xterm.
9) drop the selection in xterm
10) ^V paste into notepad: it hangs for a few seconds and doesn't paste.
(The paste menu option is NOT greyed out at this point).
Yes, that is reproducible for me now. I think I have some ideas as to
what might be causing the problem.

Harold
Ben Jackson
2004-03-26 21:39:22 UTC
Permalink
another test case: copy anything from nedit into any windows app... hangs
for 3 secs

----- Original Message -----
From: "Harold L Hunt II" <***@msu.edu>
To: <cygwin-***@cygwin.com>
Sent: Friday, March 26, 2004 6:18 PM
Subject: Re: test case for clipboard hang?
Post by Harold L Hunt II
Lev,
Post by Lev Bishop
However, I've repeated the following procedure 3 times and it worked the
same each time -- probably not a minimal test case but it shows the
1) Reboot
2) start a fresh xwin, xterm, notepad, and put some text in the xterm and
notepad
3) select, ^C copy from notepad, middle-click in xterm. it pastes
successfully
4) select in xterm, leave the text reverse-videoed
5) ^V paste into notepad (successfully)
6) drop the selection in xterm (by left clicking somewhere)
7) ^V paste into notepad (successfully, even though the selection is
dropped)
8) select a different piece of text in xterm.
9) drop the selection in xterm
10) ^V paste into notepad: it hangs for a few seconds and doesn't paste.
(The paste menu option is NOT greyed out at this point).
Yes, that is reproducible for me now. I think I have some ideas as to
what might be causing the problem.
Harold
Harold L Hunt II
2004-03-26 22:59:33 UTC
Permalink
Lev,
Post by Lev Bishop
1) Reboot
2) start a fresh xwin, xterm, notepad, and put some text in the xterm and
notepad
3) select, ^C copy from notepad, middle-click in xterm. it pastes
successfully
4) select in xterm, leave the text reverse-videoed
5) ^V paste into notepad (successfully)
6) drop the selection in xterm (by left clicking somewhere)
7) ^V paste into notepad (successfully, even though the selection is
dropped)
8) select a different piece of text in xterm.
9) drop the selection in xterm
10) ^V paste into notepad: it hangs for a few seconds and doesn't paste.
(The paste menu option is NOT greyed out at this point).
The problem was that copying something in Notepad caused the clipboard
integration manager to take ownership of both the PRIMARY and CLIPBOARD
selections in X. Selecting text in an xterm took ownership of the
PRIMARY selection away from the clipboard manager. Unselecting the text
in xterm released ownership of the PRIMARY selection, but left the
CLIPBOARD selection supposedly owned by the clipboard integration
manager (which means it thought it had text to copy from Win32 to X, but
it didn't).

I changed the behavior slightly to release ownership of the Win32
clipboard and mark both X selections as unowned if one of the selections
in X is released and the other is owned by the clipboard integration
manager. In fact, I should take this one further and release ownership
of any selection owned by the clipboard integration manager when
something is selected in X. The current fix will probably work in 90%
of cases for the time being.

I'd really appreciate some feedback on the new fix in
XFree86-xserv-4.3.0-63, which should be hitting mirrors within a few hours.

Harold
Ed Avis
2004-03-29 11:45:25 UTC
Permalink
Post by Harold L Hunt II
Post by Lev Bishop
1) Reboot
2) start a fresh xwin, xterm, notepad, and put some text in the xterm and
notepad
3) select, ^C copy from notepad, middle-click in xterm. it pastes
successfully
4) select in xterm, leave the text reverse-videoed
5) ^V paste into notepad (successfully)
6) drop the selection in xterm (by left clicking somewhere)
7) ^V paste into notepad (successfully, even though the selection is
dropped)
8) select a different piece of text in xterm.
9) drop the selection in xterm
10) ^V paste into notepad: it hangs for a few seconds and doesn't paste.
(The paste menu option is NOT greyed out at this point).
I'd really appreciate some feedback on the new fix in
XFree86-xserv-4.3.0-63, which should be hitting mirrors within a few hours.
Yes, I can reproduce the hang with 4.3.0-50 (actually, I used xemacs not xterm)
but it does not hang in 4.3.0-63. After I drop the X selection it is no longer
in the Windows clipboard, so that I cannot paste into Notepad. I don't know if
this is consistent with cut and paste on a native X desktop, but it is a massive
improvement over hanging. Thanks!
--
Ed Avis <***@membled.com>
Harold L Hunt II
2004-03-29 20:18:49 UTC
Permalink
Ed,
Post by Ed Avis
Post by Harold L Hunt II
Post by Lev Bishop
1) Reboot
2) start a fresh xwin, xterm, notepad, and put some text in the xterm and
notepad
3) select, ^C copy from notepad, middle-click in xterm. it pastes
successfully
4) select in xterm, leave the text reverse-videoed
5) ^V paste into notepad (successfully)
6) drop the selection in xterm (by left clicking somewhere)
7) ^V paste into notepad (successfully, even though the selection is
dropped)
8) select a different piece of text in xterm.
9) drop the selection in xterm
10) ^V paste into notepad: it hangs for a few seconds and doesn't paste.
(The paste menu option is NOT greyed out at this point).
I'd really appreciate some feedback on the new fix in
XFree86-xserv-4.3.0-63, which should be hitting mirrors within a few hours.
Yes, I can reproduce the hang with 4.3.0-50 (actually, I used xemacs not xterm)
but it does not hang in 4.3.0-63. After I drop the X selection it is no longer
in the Windows clipboard, so that I cannot paste into Notepad.
Thank you. It is good to know that this is confirmed as fixed for the
time being.
Post by Ed Avis
I don't know if
this is consistent with cut and paste on a native X desktop, but it is a massive
improvement over hanging. Thanks!
I'm willing to be it is consistent. We monitor the PRIMARY and
CLIPBOARD selections... most apps set one or the other. We still
advertise to Win32 that we have data to paste if either PRIMARY or
CLIPBOARD is owned by an X application other than the clipboard
integration manager. The problem before was that we didn't stop
advertising data to paste when both PRIMARY and CLIPBOARD were not owned
by valid X applications; the reason for this is that the clipboard
manager looked like a valid X app and it owned at least one of PRIMARY
and CLIPBOARD still, so we kept advertising data to paste. The failure
mode for this was inconsistent: the first time seemed to grab data from
the X application that used to own the selection while the second time
might have tried grabbing data from the clipboard manager for the
clipboard manager to paste, which lead to a deadlock.

Simple test case: don't use "-clipboard", select some text in a xterm,
unselect it, then right-click in another xterm... I don't think you'll
see any text pasted unless there is a clipboard manager of some sort
running (i.e. don't do this in Xdmcp).

Harold
A***@msg.de
2004-03-26 11:23:33 UTC
Permalink
Hi,
Post by Lev Bishop
1) Reboot
2) start a fresh xwin, xterm, notepad, and put some text in the xterm and
notepad
3) select, ^C copy from notepad, middle-click in xterm. it pastes
successfully
4) select in xterm, leave the text reverse-videoed
5) ^V paste into notepad (successfully)
6) drop the selection in xterm (by left clicking somewhere)
7) ^V paste into notepad (successfully, even though the selection is
dropped)
8) select a different piece of text in xterm.
9) drop the selection in xterm
10) ^V paste into notepad: it hangs for a few seconds and doesn't paste.
(The paste menu option is NOT greyed out at this point).
Its also reproduceable here with Harolds docu, and I get another bug.
After the 3 Sec hang in the notpad, some time late ca 1 min. The Mouse
Curser disapears over the xterm, and when that happens, the xserver
couldnt be stoped anymore, and somtimes the refresh of the xterm windows
stops also causing some wired effekts.


See you
Andreas
Lev Bishop
2004-03-30 07:43:17 UTC
Permalink
Well, I've kicked the -63 server around a fair bit this weekend and it
seems to be holding up very well. No crashes, and generally no unpleasant
surprises. I have still managed to activate the "2 second timeout" code,
though, by doing some pathological things, that are probably impossible to
work around due to the incompatibilities between the X and Windows
conceptions of the clipboard.

Harold: In winClipboardFlushXEvents, I think the line:
iReturn = XChangeProperty (pDisplay,
event.xselectionrequest.requestor,
event.xselectionrequest.property,
event.xselectionrequest.target,
8,
PropModeReplace,
(char *) atomTargetArr,
sizeof (atomTargetArr));
should have 32 instead of 8.

Also, re the following, changelog, can you tell me where to find the
changes. I see no calls to XSync or select at
http://pdx.freedesktop.org/cgi-bin/viewcvs.cgi/xc/programs/Xserver/hw/xwin/winclipboardxevents.c?rev=1.1.4.1.2.15&root=xorg&only_with_tag=CYGWIN&view=auto
and I'd like to see the code that does this.

Release 4.3.0-61
Released: 2004-03-25 0055 EST
Download source: Now available as src package via setup.exe
Changes:
winclipboardwndproc.c, winclipboardxevents.c - Attempt to fix clipboard
deadlock that was causing hangs. The nature of the fix was to stop calling
XPeekIfEvent since it will block until the specified type of event is
seen. Instead, we call XSync to flush output events and wait for them to
be processed, then we do our own little loop with a call to select() using
a timeout of 3 seconds from when we started (the timeout is adjusted after
each call to select()). This should alleviate problems with XPeekIfEvent
not returning. Finally, since we can detect whether the SelectionNotify
event has arrived now, I added code to paste NULL to the Win32 clipboard
if the X11 application never returns any useful clipboard data; this
should prevent Win32 applications from freezing when there are problems
pasting from X11 to Win32. (Harold L Hunt II - CodeWeavers)
Harold L Hunt II
2004-03-30 15:02:34 UTC
Permalink
Lev,
Post by Lev Bishop
Well, I've kicked the -63 server around a fair bit this weekend and it
seems to be holding up very well.
That is good.
Post by Lev Bishop
No crashes, and generally no unpleasant
surprises. I have still managed to activate the "2 second timeout" code,
though, by doing some pathological things, that are probably impossible to
work around due to the incompatibilities between the X and Windows
conceptions of the clipboard.
No, this is because I didn't really fix the problem, as I mentioned in
my release notes. The way I fixed it only happens if the X app you were
using just happens to set only the PRIMARY selection; a slightly
different form of the problem probably still exists if an X app sets
only the CLIPBOARD selection. I know xterm sets only the PRIMARY
seleciton, perhaps the app you were using sets only the CLIPBOARD selection.

Also, there is no fundamental incompatibility here, only an imperfect
handling of all of the cases that we need to handle. We can do this
perfectly, it is just confusing and takes time to get it correct. So I
am going to release 4.3.0-66 and you're going to test it. :)
Post by Lev Bishop
iReturn = XChangeProperty (pDisplay,
event.xselectionrequest.requestor,
event.xselectionrequest.property,
event.xselectionrequest.target,
8,
PropModeReplace,
(char *) atomTargetArr,
sizeof (atomTargetArr));
should have 32 instead of 8.
Seems logical to me. I changed it. I also changed the cast from (char
*) to (unsigned char*) since that is what XChangeProperty is expecting.
Post by Lev Bishop
Also, re the following, changelog, can you tell me where to find the
changes. I see no calls to XSync or select at
http://pdx.freedesktop.org/cgi-bin/viewcvs.cgi/xc/programs/Xserver/hw/xwin/winclipboardxevents.c?rev=1.1.4.1.2.15&root=xorg&only_with_tag=CYGWIN&view=auto
and I'd like to see the code that does this.
Simple: I dropped that patch on the floor somewhere so it never got into
CVS. I fixed it now. Thanks for the heads up. Its amazing that
everything compiled and future patches kept applying even without those
changes in there.

Harold
Lev Bishop
2004-03-30 16:35:43 UTC
Permalink
Post by Harold L Hunt II
Also, there is no fundamental incompatibility here, only an imperfect
handling of all of the cases that we need to handle. We can do this
perfectly, it is just confusing and takes time to get it correct. So I
am going to release 4.3.0-66 and you're going to test it. :)
I think there is a fundamental incompatibility, due to the following.
Windows thinks of the clipboard as a fixed, centralized thing, that
doesn't change or delete data without specific user action (a useful
conception from a user-friendliness point of view). X allows selections to
change, get dropped due to the client getting disconnected, because the
clipboard is not centralized but kept with each client (a useful
conception when clients are accross a network from each other). Windows
allows apps to delay rendering of clipboard data, but only insofar as from
the user's point of view the behaviour is the same as if the data were
saved to the clipboard in their final form at the time of the copy/cut
action. An implication of this is that if the clipboard holds the same
data in multiple formats, all the formats should still be the same data,
eg, the same string in unicode and ascii.

Can you see a problem? It is possible (and I have done it) for there to
be 4 different conceptions of the clipboard, all holding different data!
To demonstrate this, do something like: assert the PRIMARY selection by
selecting text in an xterm; assert the CLIPBOARD selection by running
xclipboard; type some text into xlipboard and paste the text as unicode
into windows, eg edit->paste in excel; change the text in xclipboard and
paste the text as plain text, eg using "paste special" in excel; finally
change the text in xclipboard. At this point, there are 4 different
"clipbaord contents", no two of them the same. X clients that ask for
PRIMARY get one thing, ones that ask for CLIPBOARD get another, windows
apps get 2 different things depending on whether they ask for unicode or
plain text. This breaks the windows clipboard idiom of the data being
fixed and immutable, and "the clipboard" being a consistent concept with
just one thing in it, stored in different formats.

I can't see a way around this issue.

Another issue is that in windows, data doesn't get deleted from the
clipboard unless you specifically ask it to be, or replace it with
something new. Especially, if you've successfully pasted something,
demonstrating that the clipboard has the data you want, that data won't
disappear unless you do something to get rid of it. Now, the x PRIMARY
selection is much more ephemeral than this, and it gets dropped all the
time. The recent patches in -63 mean that the windows clipboard
(correctly) gets cleared at the same time as the selection is dropped, if
the text has not yet been rendered. However, after pasting from X to
windows, the clipboard doesn't get cleared when the selection is dropped.
I can't work out which part of the code is responsible for this behaviour,
but it works, and this is the right thing(TM) because now the windows user
can paste repeatedly, even if the original X client has been killed, in
the way that windows clipboard usually functions. But here there is also a
problem: if the selection is dropped after the text has been rendered in
one format (say unicode) but not in another (say plain text), then,
because there is no way at this point for xwinclip to retrieve the plain
text from the client, it cannot honour its promise to render the plain
text content of the clipboard. (This is how I was able to activate the "2
second timeout" code, by the way: make an X selection, paste it as
unicode, drop the selection, attempt to paste as plain text).

There's no easy way around this one either.

But, as I said, these are pretty pathological cases. So long as nothing
crashes in these cases, I think that is good enough.

Lev
Harold L Hunt II
2004-03-30 17:10:16 UTC
Permalink
Lev,
Post by Lev Bishop
Post by Harold L Hunt II
Also, there is no fundamental incompatibility here, only an imperfect
handling of all of the cases that we need to handle. We can do this
perfectly, it is just confusing and takes time to get it correct. So I
am going to release 4.3.0-66 and you're going to test it. :)
I think there is a fundamental incompatibility, due to the following.
Windows thinks of the clipboard as a fixed, centralized thing, that
doesn't change or delete data without specific user action (a useful
conception from a user-friendliness point of view). X allows selections to
change, get dropped due to the client getting disconnected, because the
clipboard is not centralized but kept with each client (a useful
conception when clients are accross a network from each other). Windows
allows apps to delay rendering of clipboard data, but only insofar as from
the user's point of view the behaviour is the same as if the data were
saved to the clipboard in their final form at the time of the copy/cut
action.
That last sentence is not correct. Here is how delayed rendering works:

http://msdn.microsoft.com/library/en-us/winui/winui/windowsuserinterface/dataexchange/clipboard/clipboardoperations.asp?frame=true#_win32_Delayed_Rendering

You'll notice in the clipboard integration source code that we advertise
support for a format, but we only paste the data if it is still there;
if the data is not there anymore, then we paste null data to satisfy the
requirement that we paste something. This handles all of the cases were
the X selection is lost for some reason or another and we are not
notified about it synchronously.
Post by Lev Bishop
An implication of this is that if the clipboard holds the same
data in multiple formats, all the formats should still be the same data,
eg, the same string in unicode and ascii.
No, that is not correct. I can advertise CF_TEXT and CF_BITMAP and have
a text that says "goat" and a bitmap rendering of a frog if I want.
There is no requirement that the formats all contain the same data.
Post by Lev Bishop
Can you see a problem? It is possible (and I have done it) for there to
be 4 different conceptions of the clipboard, all holding different data!
To demonstrate this, do something like: assert the PRIMARY selection by
selecting text in an xterm; assert the CLIPBOARD selection by running
xclipboard; type some text into xlipboard and paste the text as unicode
into windows, eg edit->paste in excel; change the text in xclipboard and
paste the text as plain text, eg using "paste special" in excel; finally
change the text in xclipboard. At this point, there are 4 different
"clipbaord contents", no two of them the same. X clients that ask for
PRIMARY get one thing, ones that ask for CLIPBOARD get another, windows
apps get 2 different things depending on whether they ask for unicode or
plain text. This breaks the windows clipboard idiom of the data being
fixed and immutable, and "the clipboard" being a consistent concept with
just one thing in it, stored in different formats.
I think part of what is happening here is that you are getting confused
by the "feature" I added that intentionally lets PRIMARY and CLIPBOARD
be different in X and only advertises the most recently changed one to
Windows. However, it sounds like you may have found some sort of bug in
the unicode handling... could you elaborate on what gets pasted if a in
the cases were a Win32 app requests non-unicode and another Win32 app
requests unicode text?
Post by Lev Bishop
Another issue is that in windows, data doesn't get deleted from the
clipboard unless you specifically ask it to be, or replace it with
something new.
No, it does when you use delayed rendering, which is part of the reason
we use delayed rendering. This is not a big deal: we advertised
something, it disappeared, *important* no other X or Win32 app placed
something on the clipboard after we did, and we say "oops, the data is
missing, sorry". What is the problem there? We owned the clipboard and
didn't disrupt any other application from using it.
Post by Lev Bishop
Especially, if you've successfully pasted something,
demonstrating that the clipboard has the data you want, that data won't
disappear unless you do something to get rid of it.
You must not have worked with applications that give you the famous "you
have copied a large amount of data to the clipboard, would you like to
remove it to same memory" dialog box that pops up a few minutes after
copying large data to the clipboard; some apps that use delayed
rendering do the same thing when they exit but without warning: they
just don't paste anything when they get a WM_RENDERALLFORMATS on exit.
Post by Lev Bishop
Now, the x PRIMARY
selection is much more ephemeral than this, and it gets dropped all the
time. The recent patches in -63 mean that the windows clipboard
(correctly) gets cleared at the same time as the selection is dropped, if
the text has not yet been rendered.
Yes, that is correct.
Post by Lev Bishop
However, after pasting from X to
windows, the clipboard doesn't get cleared when the selection is dropped.
Uhh... that is what we just fixed.

I just tested it:

1) select text in xterm
2) paste in notepad
3) drop selection in xterm
4) right-click in notepad, see that paste is greyed out

If you are still seeing this then it is a more sophisticated bug than
the recent fix was designed for and it may be the bug that I am
currently working on, but it is hard to say.
Post by Lev Bishop
I can't work out which part of the code is responsible for this behaviour,
but it works, and this is the right thing(TM) because now the windows user
can paste repeatedly, even if the original X client has been killed, in
the way that windows clipboard usually functions.
No, this is not correct. If the data is gone we shouldn't be pasting it
because it means that we are likely referencing an already freed pointer
and it will lead to random crashes.

It is remotely possible that we may be able to request selection
contents when an X app is about to exit so that we can make a static
copy of that text on the clipboard, but I don't know of a way to do this
and it isn't important enough for me to spend time on right now.
Post by Lev Bishop
But here there is also a
problem: if the selection is dropped after the text has been rendered in
one format (say unicode) but not in another (say plain text), then,
because there is no way at this point for xwinclip to retrieve the plain
text from the client, it cannot honour its promise to render the plain
text content of the clipboard.
This is probably due to some changes that Kensuke and I were making to
which formats we advertised... I am real leary of changing this since it
tends to break things on Japanese computers. I'm not sure if pasting
NULL for CF_TEXT when we paste real CF_UNICODETEXT data would cause
Windows to automatically convert from CF_UNICODETEXT to CF_TEXT like it
says it will. Might be worth a try.
Post by Lev Bishop
(This is how I was able to activate the "2
second timeout" code, by the way: make an X selection, paste it as
unicode, drop the selection, attempt to paste as plain text).
Interesting.
Post by Lev Bishop
There's no easy way around this one either.
I wouldn't be so sure about that.
Post by Lev Bishop
But, as I said, these are pretty pathological cases. So long as nothing
crashes in these cases, I think that is good enough.
No, it needs to be better.

Harold
Lev Bishop
2004-03-30 16:53:27 UTC
Permalink
Post by Harold L Hunt II
Simple test case: don't use "-clipboard", select some text in a xterm,
unselect it, then right-click in another xterm... I don't think you'll
see any text pasted unless there is a clipboard manager of some sort
running (i.e. don't do this in Xdmcp).
Actually, you generally *will* see text pasted in this situation: xterm,
as it is usually configured, makes use of CUT_BUFFER0, the obsolete way of
doing cutting and pasting, that is more like windows than x selections.

Lev
Lev Bishop
2004-03-30 18:11:30 UTC
Permalink
Post by Harold L Hunt II
http://msdn.microsoft.com/library/en-us/winui/winui/windowsuserinterface/dataexchange/clipboard/clipboardoperations.asp?frame=true#_win32_Delayed_Rendering
You'll notice in the clipboard integration source code that we advertise
support for a format, but we only paste the data if it is still there; if
the data is not there anymore, then we paste null data to satisfy the
requirement that we paste something. This handles all of the cases were
the X selection is lost for some reason or another and we are not notified
about it synchronously.
I think you're misunderstanding the delayed rendering in windows. The
important thing is that *you only get one chance to render delayed* after
that, the rendered data is saved staticly to the clipboard and windows
serves up requests for that data directly without involving your program.
Setting delayed rendering for a format is like writing an IOU for that
format, but once windows has collected on the IOU it doesn't try to ask
you to pay twice, it only needs to be told the data once.
Post by Harold L Hunt II
An implication of this is that if the clipboard holds the same data in
multiple formats, all the formats should still be the same data, eg, the
same string in unicode and ascii.
No, that is not correct. I can advertise CF_TEXT and CF_BITMAP and have a
text that says "goat" and a bitmap rendering of a frog if I want. There is
no requirement that the formats all contain the same data.
But you surely agree that the user is expecting that at least the CF_TEXT
and CF_BITMAP that you paste both came from the state of the clipboard at
a given snapshot in time?
Post by Harold L Hunt II
I think part of what is happening here is that you are getting confused by
the "feature" I added that intentionally lets PRIMARY and CLIPBOARD be
different in X and only advertises the most recently changed one to
Windows.
I know that PRIMARY and CLIPBOARD are intentionally different in X, and it
is good that xwinclip respects this important aspect of X behaviour, but
it makes the mapping between X and windows more complicated.
Post by Harold L Hunt II
However, it sounds like you may have found some sort of bug in
the unicode handling... could you elaborate on what gets pasted if a in
the cases were a Win32 app requests non-unicode and another Win32 app
requests unicode text?
When a win32 app requests non-unicode, if non-unicode has never been
rendered for this selection then the current value of the selection gets
rendered to non-unicode; if non-unicode has already been rendered for this
selection then whatever the value of the selection was at the time it was
rendered gets pasted. The same is true for unicode: if unicode has not
been rendered for this selection, then the current value of the selection
gets rendered as unicode, if unicode has been rendered then the prior
value of the selection is returned. The chance for there to be a
difference between what is returned to win32 for unicode and what is
returned to win32 for non-unicode comes in if the value of the selection
changes between the requests. Some X clients do not reassert the selection
every time the value of the selection changes (eg xclipboard is one) to
minimize traffic to the server (this is encouraged in the ICCCM).

I don't think this is a bug in the unicode -- the unicode is treated in
the same way as the plain text. The problem is that potentially the
unicode and plain text entries in the clipboard can be from different
times and hence be different to each other.
Post by Harold L Hunt II
No, it does when you use delayed rendering, which is part of the reason we
use delayed rendering. This is not a big deal: we advertised something, it
disappeared, *important* no other X or Win32 app placed something on the
clipboard after we did, and we say "oops, the data is missing, sorry".
What is the problem there? We owned the clipboard and didn't disrupt any
other application from using it.
The problem here is that the user cuts 2 pages out of a document he's
working on to the clipboard, then goes to paste it and we say "oops, the
data is missing, sorry" and the user says "damn, now I have to type those
2 pages out again".
Post by Harold L Hunt II
Especially, if you've successfully pasted something,
demonstrating that the clipboard has the data you want, that data won't
disappear unless you do something to get rid of it.
You must not have worked with applications that give you the famous "you
have copied a large amount of data to the clipboard, would you like to
remove it to same memory" dialog box that pops up a few minutes after
copying large data to the clipboard; some apps that use delayed rendering
do the same thing when they exit but without warning: they just don't
paste anything when they get a WM_RENDERALLFORMATS on exit.
The former behaviour is acceptable, because it gives the user a chance to
avoid losing his data, the latter behaviour, while it does exist, is a
badly written app.
Post by Harold L Hunt II
However, after pasting from X to
windows, the clipboard doesn't get cleared when the selection is dropped.
Uhh... that is what we just fixed.
1) select text in xterm
2) paste in notepad
3) drop selection in xterm
4) right-click in notepad, see that paste is greyed out
I do this, and paste is *not* greyed out in this case. And in fact the
paste actually works, too, because we have already rendered the text to
the clipboard, so the data is there and we don't need the original X
selection any more because it is actually stored in the clipboard. I want
to keep this behaviour -- I consider it a feature, not a bug.

On the other hand, if you skip step 2, then paste is indeed greyed out,
and this is also the right thing, because at this point we don't have the
text available to paste.
Post by Harold L Hunt II
I can't work out which part of the code is responsible for this behaviour,
but it works, and this is the right thing(TM) because now the windows user
can paste repeatedly, even if the original X client has been killed, in
the way that windows clipboard usually functions.
No, this is not correct. If the data is gone we shouldn't be pasting it
because it means that we are likely referencing an already freed pointer
and it will lead to random crashes.
NO! The data has already been rendered! You only have to render (only get
a chance to render) each type of data *ONCE*, and then it is there, in the
clipboard, in static form. Why would we want to go and delete perfectly
good clipboard data, that windows is serving up for us without needing
any further help from us?
Post by Harold L Hunt II
It is remotely possible that we may be able to request selection contents
when an X app is about to exit so that we can make a static copy of that
text on the clipboard, but I don't know of a way to do this and it isn't
important enough for me to spend time on right now.
This might work, if we could reliably tell when the X app is about to
exit or lose its network connection or whatever. I think this will be
hard.

I still think we can't really do much better given the limitations of the
windows vs X paradigms. More interesting is to try to add support for
additional formats. Another thing is to add support for the INCR method of
pasting large amounts to the clipboard. Currently the clipboard
integration can't deal with clients being considerate and using INCR
for large pastes rather than blasting the data out all in one go.

Lev

Continue reading on narkive:
Loading...