"Paste" from clipboard can failed (XWin bug)

[Jon TURNEY]

On 30/09/2010 15:28, rolandc wrote:
>  From X application, I select some text. I switch on Windows
> application and I try to paste the text.
> I do "Ctrl-V" =>  nothing happens
> I do a second "Ctrl-V" =>  the text is pasted
>
> This problem depends on the X application

For testing purposes, do you have an example of an application which only 
offers XA_STRING?

> When a "paste" occurs, XWin receives a WM_RENDERFORMAT message :
> (cf. winClipboardWindowProc())
>
> step 1/ XWin try to get the selection in COMPOUND_TEXT format
>      (cf. winProcessXEventsTimeout() calls XConvertSelection("COMPOUND_TEXT "))
>
> step 2/ If the owner of the selection (the X app) can't handle
> COMPOUND_TEXT format, XWin try to get the selection in UTF8_STRING
> format
>      (cf. winClipboardFlushXEvents(), on receive an SelectionNotify
> event with "event.xselection.property == None", XWin calls
> XConvertSelection("UTF8_STRING"))
>
> step 3/ If the owner of the selection (the X app) can't handle
> UTF8_STRING format, XWin try to get the selection in XA_STRING format
>      (cf. winClipboardFlushXEvents(), on receive an SelectionNotify
> event with "event.xselection.property == None", XWin calls
> XConvertSelection("XA_STRING"))
>
> But there is a bug in XWin :
> XWin calls winProcessXEventsTimeout() only twice. If the X app handles
> only handles XA_STRING format, the "step 3" is never invoked !
> As the result, XWin can't get "paste data" and log the message:
>      "winClipboardWindowProc - timed out waiting for WIN_XEVENTS_NOTIFY"
>

Thanks very much for investigating this problem.

> Solution 1 :
> Call a third time the function winProcessXEventsTimeout()
> (see paste_bug_solution1.patch file attached)
> but this is not a very elegant solution ...
>
> Solution 2 :
> call winProcessXEventsTimeout() only one time
> winProcessXEventsTimeout() must process all notification until
> * time out expired
> * getting the paste data
> * error occurred
> (see paste_bug_solution2.patch file attached)
>
> note: the actual timeout is set to 1 second.

Thanks very much for the patch.  I agree that (2) is the more elegant solution.

I am actually a bit concerned about the size of the timeout, it's conceivable 
a remote X application could take longer than that to respond.

However, since we are trying to do this conversion synchronously in the 
clipboard thread's message pump, I'm not sure we want to block longer.


-- 
Jon TURNEY
Volunteer Cygwin/X X Server maintainer

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