qclipboard_x11 problems (was: Re: Fwd: killer bug (klipper ?))

[Lubos Lunak]

On Thursday 24 October 2002 11:45, Lubos Lunak wrote:
> On Thursday 24 October 2002 09:19, Andras Mantia wrote:
> > On 2002. October 24., Thursday 04:08, Michael Brade wrote:
> > > On Wednesday 23 October 2002 23:56, Christoph Cullmann wrote:
> > > > On Wednesday 23 October 2002 23:42, Malte Starostik wrote:
> > > > > > 
> > > > > > I'm running latest stuff from head, and just noticed that
> > > > > > following trick locks up any editor ( tried kate, kwrite and kword 
> > > > > > ). Type any word, then hit shift-home to select it. Then hit
> > > > > >  ctrl+c to copy it and try to move cursor with arrows. That's it.
> > > > > >  Apps dead, and stays that way. Trick seems to be always
> > > > > >  reproducable on my boxes.
> > > > > > 
> > > > > > Could somebody retest that with kword ? (have no working copy
> > > > > > here atm) If it is not reproducable with kword, it's a curious
> > > > > > kate part bug I need
> > >
> > > Jep, same here. I guess it's the "Prevent empty clipboard" in Klipper,
> > > I disabled that and switched to "Separate clipboard and selection" as
> > > well, that fixed it for me.
>
>  I tried updating everything I considered relevant, and I still can
> reproduce the problem (I didn't a complete clean update though). It happens
> when Klipper is set to any of the two policies which try to synchronize
> selection and clipboard. It doesn't happen with Qt-3.0.x though, so it's
> either a bug introduced in Qt-3.1, or some Qt change has triggered some
> flaw in KClipboard (ranting, mumbling and sighing snipped).
>
>  I'll have a look at it.

 Ok, problem found. I've already commited the KClipboard part of the fix. The 
Qt part of the fix is attached (together with some small details I noticed).

 As always, the problem was that the app was trying to read the clipboard 
contents from itself over the Xserver. I added a check+qWarning in case this 
problem ever happens again (but I hope I won't have to mess with QClipboard 
yet once more).

 The patch also removes clipboard data clearing upon receiving 
SelectionNotify. Unless I'm missing something, the app can receive 
SelectionNotify when it's not waiting for it only when it times out waiting 
for the result of XConvertSelection(). I generally don't understand the 
purpose of the code after 'case SelectionNotify:', I don't see the point of 
clearing the clipboard data after receiving SelectionNotify. It was causing 
the problem by clearing the clipboard data, but the application still kept 
the selection ownership, and when some other app did XConvertSelection() 
resulting in SelectionRequest, the app tried to read the clipboard contents 
using QClipboardWatcher, instead of simply using (the now cleared) clipboard 
data.

 Morever, I noticed the code didn't check for possible 
xevent.xselection.property being None (possible when the other app refuses 
the send the clipboard data), and also the comment about about the 
XGetSelectionOwner() after XSetSelectionOwner() seems to be wrong, at least 
according to ICCCM section 2.1.

-- 
Lubos Lunak
KDE developer
---------------------------------------------------------------------
SuSE CR, s.r.o.  e-mail: l.lunak at suse.cz , l.lunak at kde.org
Drahobejlova 27  tel: +420 2 9654 2373
190 00 Praha 9   fax: +420 2 9654 2374
Czech Republic   http://www.suse.cz/
-------------- next part --------------
A non-text attachment was scrubbed...
Name: qclipboard_x11.cpp.patch
Type: text/x-diff
Size: 1782 bytes
Desc: not available
URL: <http://mail.kde.org/pipermail/kde-core-devel/attachments/20021024/57e8c955/attachment.patch>