Bug 229439 - "copy link address" doesn't properly synchronize with selection
Summary: "copy link address" doesn't properly synchronize with selection
Status: RESOLVED WORKSFORME
Alias: None
Product: klipper
Classification: Unmaintained
Component: general (other bugs)
Version First Reported In: unspecified
Platform: Compiled Sources Unspecified
: NOR normal
Target Milestone: ---
Assignee: Martin Flöser
URL:
Keywords:
: 265619 (view as bug list)
Depends on:
Blocks:
 
Reported: 2010-03-04 20:36 UTC by Jacopo De Simoi
Modified: 2020-01-13 11:00 UTC (History)
6 users (show)

See Also:
Latest Commit:
Version Fixed/Implemented In:
Sentry Crash Report:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Jacopo De Simoi 2010-03-04 20:36:18 UTC
Version:            (using Devel)
Installed from:    Compiled sources

(running 4.4 branch)

The synchronize option in the primary->selection sense doesn't work when copying with the "copy link address"  action; i.e.:

1) "copy link address" on some link in konqueror
2) middle click gives the old selection content
3) paste gives the link address, as expected.

expected behavior: middle click gives the link address

Thanks 
 __J
Comment 1 Jacopo De Simoi 2010-03-05 16:35:15 UTC
more info: 

* in fact synchronizing works correctly when copying a link from an akregator tab or from konsole; 
* copying links from arora or quassel works correctly
* copying links from khtml or kdewebkit kparts (in konqueror or akregator) fails (i.e. does not synchronize)
Comment 2 David de Cos 2010-07-01 11:18:49 UTC
I've noticed this behavior too, but in my case it works eventually, you just have to wait. Steps to reproduce:

- Copy e-mail address in KMail, or any link in Firefox/Konqueror, using "copy link address" option.

- If you try middle-click immediately, it doesn't paste anything.

- If you click on the Klipper icon immediately, nothing happens.

- After waiting for about 10 seconds, everything works again: you can middle-click to paste the selection, the klipper window shows up, etc.
Comment 3 Jekyll Wu 2011-11-06 19:49:53 UTC
I can observe the same behavior as mentioned in comment #2. I am using KDE 4.7.3
Comment 4 Jekyll Wu 2011-12-24 04:19:57 UTC
*** Bug 265619 has been marked as a duplicate of this bug. ***
Comment 5 Jekyll Wu 2011-12-25 02:52:59 UTC
Ok, I just checked it again. The result is slightly different 

1). The problem does not happen when using firefox. Konqueror is a good choice for reproducing the problem.
2). Immediately after 'copy link address', Ctrl-V does not work, but paste-by-middle-click still works.
Comment 6 Jekyll Wu 2011-12-25 02:55:09 UTC
Here is the backtrace when klipper hangs after clicking the icon:

#0  0xb77c2424 in __kernel_vsyscall ()
#1  0xb60f0941 in select () from /lib/libc.so.6
#2  0xb6440289 in QX11Data::clipboardWaitForEvent (this=0x8faf100, win=52428898, 
    type=31, event=0xbfedda68, timeout=5000) at kernel/qclipboard_x11.cpp:588
#3  0xb6442c3f in QClipboardWatcher::getDataInFormat (this=0x93eb5a0, fmtatom=351)
    at kernel/qclipboard_x11.cpp:1280
#4  0xb6443112 in QClipboardWatcher::formats_sys (this=0x93eb5a0)
    at kernel/qclipboard_x11.cpp:1205
#5  0xb63c6d27 in QString (aLatin1=<optimized out>, this=0xbfeddb88)
    at ../../include/QtCore/../../src/corelib/tools/qstring.h:694
#6  QInternalMimeData::formats (this=0x93eb5a0) at kernel/qdnd.cpp:354
#7  0xaee26713 in Klipper::checkClipData (this=0x9090570, selectionMode=false)
    at /home/whodare/code/kde/workspace/klipper/klipper.cpp:694
#8  0xaee28d01 in Klipper::qt_static_metacall (_o=0x9090570, 
    _c=QMetaObject::InvokeMetaMethod, _id=22, _a=0xbfeddd58)
    at /home/whodare/code/kde/workspace/klipper/build/klipper/klipper.moc:127
#9  0xb6ebf292 in QMetaObject::activate(QObject*, QMetaObject const*, int, void**)
    () from /usr/lib/qt4/libQtCore.so.4
#10 0xb6aa50b4 in QClipboard::selectionChanged (this=0x8f7a420)
    at .moc/release-shared/moc_qclipboard.cpp:115
#11 0xb643b2d5 in QApplication::x11ProcessEvent (this=0xbfede440, event=0xbfede0e0)
    at kernel/qapplication_x11.cpp:3459
#12 0xb6465212 in x11EventSourceDispatch (s=0x8faec90, callback=0, user_data=0x0)
    at kernel/qguieventdispatcher_glib.cpp:149
#13 0xb5aee4f2 in g_main_context_dispatch () from /usr/lib/libglib-2.0.so.0
#14 0xb5aeed08 in ?? () from /usr/lib/libglib-2.0.so.0
#15 0xb5aeef25 in g_main_context_iteration () from /usr/lib/libglib-2.0.so.0
#16 0xb6eda71d in QEventDispatcherGlib::processEvents(QFlags<QEventLoop::ProcessEventsFlag>) () from /usr/lib/qt4/libQtCore.so.4
#17 0xb6464e26 in QGuiEventDispatcherGlib::processEvents (this=0x8f7b010, flags=...)
    at kernel/qguieventdispatcher_glib.cpp:207
#18 0x08f7b010 in ?? ()
#19 0xb6ea722a in QEventLoop::processEvents(QFlags<QEventLoop::ProcessEventsFlag>)
    () from /usr/lib/qt4/libQtCore.so.4
#20 0xb6ea7532 in QEventLoop::exec(QFlags<QEventLoop::ProcessEventsFlag>) ()
   from /usr/lib/qt4/libQtCore.so.4
#21 0xb6eac2c1 in QCoreApplication::exec() () from /usr/lib/qt4/libQtCore.so.4
#22 0xb63af5a8 in QApplication::mainWidget () at kernel/qapplication.cpp:5105
#23 0x08f870c0 in ?? ()
#24 0xaee3f639 in kdemain (argc=1, argv=0x8f7a1c8)
    at /home/whodare/code/kde/workspace/klipper/main.cpp:50
#25 0x0804e2f1 in _start ()
Comment 7 Graeme Hewson 2012-05-15 15:37:39 UTC
I find middle click doesn't work (nothing happens), even after waiting, after copying a URL link from Konqueror, Kmail or Akregator, and trying to paste into Konsole. Ctrl+Shift+V to paste works fine.

Middle click *does* work after copying an email address from Kmail. Also copying a URL link from Firefox works fine. Using KDE 4.8.2.
Comment 8 David de Cos 2019-12-28 19:47:27 UTC
I think this got solved years ago, probably with KDE 5? Should it be marked as resolved?
Comment 9 Graeme Hewson 2019-12-29 10:45:58 UTC
Everything seems to be working OK for me now.
Comment 10 Christoph Feck 2020-01-13 11:00:31 UTC
Thanks for the update; changing status.