test case for clipboard hang?

[Harold L Hunt II]

Ed,

Ed Avis wrote:

> Harold L Hunt II <huntharo <at> msu.edu> writes:
> 
> 
>>>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.

> 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