Community
Participate
Working Groups
After upgrading from 3.1.2 to 3.2, the copy and cut functions are very flakey. Sometimes they work, sometimes they don't (seems about 50/50 if they copy the text or not). For copy, neither the X11 clipboard copy (select text) nor CTRL-C (or right-click menu Copy) work consistently. For cut, it always removes the selected text, but it doesn't copy it consistently, which is very annoying. I've found that if you repeatedly tell it to copy, it will work. My current workaround for copy is to select the text that I want, then hit CTRL-C about 5-10 times... this has always worked. My workaround for cut is to hit CTRL-C about 5-10 times, then CTRL-X. This always works. This is what it looks like when it doesn't work (again, this happens about 50% of the time): 1) select some text. 2) put the cursor somewhere else (thus deselecting the text) 3) click the middle-mouse button expected result: The selected text is copied to the mouse cursor point actual result: Some previously-selected text is pasted at the mouse cursor point. or: 1) select some text. 2) Press CTRL-C (or Edit-->Copy) 3) Put the cursor somewhere else. 4) Press CTRL-V (or Edit-->Paste) Expected result: selected text is pasted at the cursor location Actual result: some previously-selected text is pasted or: After upgrading from 3.1.2 to 3.2, the copy and cut functions are very flakey. Sometimes they work, sometimes they don't (seems about 50/50 if they copy the text or not). For copy, neither the X11 clipboard copy (select text) nor CTRL-C (or right-click menu Copy) work consistently. For cut, it always removes the selected text, but it doesn't copy it consistently, which is very annoying. I've found that if you repeatedly tell it to copy, it will work. My current workaround for copy is to select the text that I want, then hit CTRL-C about 5-10 times... this has always worked. My workaround for cut is to hit CTRL-C about 5-10 times, then CTRL-X. This always works. This is what it looks like when it doesn't work (again, this happens about 50% of the time): 1) select some text. 2) put the cursor somewhere else (thus deselecting the text) 3) click the middle-mouse button expected result: The selected text is copied to the mouse cursor point actual result: Some previously-selected text is pasted at the mouse cursor point. or: 1) select some text. 2) Press CTRL-X (or Edit-->Cut) 3) The selected text is removed as expected. 4) Put the cursor somewhere else. 5) Press CTRL-V (or Edit-->Paste) Expected result: selected text is pasted at the cursor location Actual result: some previously-selected text is pasted. paste seems to work all the time without any problems.
- does it work in dialogs and wizards or do you only see this in editors (if so, which editors)? - if it is only in the Java editor: can you uncheck the following preference: Java > Editor > Typing > [ ] Update imports >For copy, neither the X11 clipboard copy (select text) nor CTRL-C (or >right-click menu Copy) work consistently. This sounds like bug 97557. Please reopen after attaching the requested info.
I've only seen this in editors: java and JSP editor (I'm using the WST all-in-one build based on eclipse 3.2) I tried disabling the Update Imports option -- I still see the problem with it disabled. I don't think this is the same as bug 97557 because the problem didn't exist in 3.1.2 -- it emerged in 3.2.. also it's not just the X11 clipboard.
>I've only seen this in editors: java and JSP editor What about the standard text editor? Moving to SWT.
will standard text editor. Also .. some more info: eclipse.buildId=M20060628-1325 Fedora Core 5 Sun jdk1.5.0_07
Sorry .. that last comment should have started: "I'll try the standard text editor and update this bug..."
What happened with the standard text editor?
I still see the X11 copy / paste problem with the standard text editor, but I haven't seen the CTRL-C problem yet. Although .. I don't use the standard editor normally, so it's fairly superficial testing.
I've the same problem as the OP Is there any progress in this bug since it's a little anoying :-)
Martin - can you provide some more info as to which distro you're using, which build etc and a set of repro instructions. I haven't yet been able to reproduce the original failure as described in Comment 0. Also, can you try this out on a recent Eclipse 3.3 build (try the M3 milestone build). Thanks!
Okay, I will try to explain and describe my situation. I'm using Gentoo Linux with Eclipse 3.2.1 M20060921-0945 I played a bit around ant try to find a way how you can reproduce the failor. The problem is, that this only happens sometimes. It isn't always reproduceable if you follow a few steps. However, I found a piece of code and a way to copy it to the clipboard on which this seems to happen more often. I had to iterate the following steps a few times until I get the described problem that only a piece of code (not the whole marked text) was copied to the clipoard. I got it at a 1/3 chance - so you have to retry it a few times. Try this piece of code: class Papier extends JComponent { @Override protected void paintComponent(Graphics g) { // TODO Auto-generated method stub super.paintComponent(g); Graphics2D g2d = (Graphics2D)g; AffineTransform at = AffineTransform.getTranslateInstance(150, 150); g2d.transform(at); at = AffineTransform.getRotateInstance(Math.toRadians(-90.0)); g2d.transform(at); g.drawString("ZEUCH!", 0, 0); at = AffineTransform.getRotateInstance(Math.toRadians(90.0)); g2d.transform(at); at = AffineTransform.getTranslateInstance(-150, -150); g2d.transform(at); g.drawString("ZEUCH!", 150, 150); } } copy it into eclipse (the text-editor of eclipse also fails. So you don't have to use the java-editor). Now, please do this steps on the the last but one block (line 15 to 18 if you use an empty editor): 1. Click with the mouse right before the "at = AffineTransform..." (not on the 1 column, just before the 'a' character of "at = ..." 2. press shift and keep it pressed 3. use the down-arrow key 3 times to navigate to line 18. Your curser remains just befor the 'g' character of the line "g2d.transform(at);". Just let the shift key pressed. 4. press the 'end' key one time to add this line to the market text. Now, you shoud have marked all the text from line 15 col 13 until line 18 col 31 5. now, press CTRL+X to cut this text. 6. directly press CTRL+V to paste the text 7. goto 1 until you missing some text However, I fear that you won't get this problem or you already got it sometimes. But I will try the M3 build as you mentioned it. If you have another idea how I can describe this (maybe more informations about the system or make a movie of my steps?) then please let me know about it and I will try to help... Regards Martin
Created attachment 54248 [details] Screencapture of the problem I made a screencapture of my described steps. You can see, that I can successfully cut and paste the code a few times until it fails. I noticed, that in the fault-case of this procedure the CTRL-X didn't removed the text. It seems like the algorithm of CTRL-X fails somewhere during the copy of the selected text and thus break right before it finished (so the text remains marked). If you now press CTRL-V the marked text will be overriden with the fragmentary copied text from the aborted CTRL-X procedure. You can't see this in the movie, so I try to explain it as good as I can. In all my test cases (where this CUT failed), I noticed that it's always the same part of text which fails to copy to the clipoard. In my case it's always the last line. As I said, CTRL-X didn't removed the marked text in the fault-case. Well, for CTRL-X you can see that your next CTRL-V action will fail because you can see, that your marked text didn't dissapear. However, you can't see this for CTRL-C. I hope that this will help a little.. Regards, Martin
Next addon: I have the same problem with the new eclipse 3.3. Hmmm... Could this be a problem of KDE or a similar system resource which provide the clipboard functionality? I sometimes noticed a clipboard error from Eclipse (a small dialog popped up which advert me that theres a problem with the clipboard). This error dialog sometimes appear during the work with eclipse. Maybe there's a correlation between this dialog and the described problem in this bug!? Regards
I had this problem too under Gentoo and Debian. I'm using KDE and I tried and removed from the panel the Klipper applet (the cut & paste history applet) and this problem went away!
Martin, do the steps in Comment 13 work for you?
It seems, that this helps... Yes. At least I hadn't this problem again since I deactivated the applet. Maybe this is the solution...
Good to know. Darrell - does this work for you as well?
By the way, I forgot to mention that another problem I experienced was when I was trying to select a file, and copy it (e.g., to paste it in another directory): I was often getting a message box saying that there were problems accessing the clipboard, that's basically why I tried and deactivated that applet. Sometimes, the copy succeeded, but the pasting was resulting in a null pointer exception. Of course, after deactivating the applet, also this problem disappeared.
Mylar has a similiar problem: Bug 154616: [linux] Right click deselects in task editor
It looks like the root cause of this bug was that people were running the Klipper Clipboard applet which was wreaking havoc with clipboard operations in Eclipse. If anyone else is experiencing problems and is *not* running Klipper, please reopen this bug. Closing as WORKSFORME.
*** Bug 191665 has been marked as a duplicate of this bug. ***
(In reply to comment #19) > It looks like the root cause of this bug was that people were running the > Klipper Clipboard applet which was wreaking havoc with clipboard operations in > Eclipse. Does this mean you just ignore this error? Did you opened a bug report on Klipper to get this fixed?
Go ahead.
I haven't retested (mostly working on OS X now) -- but yes, I was using KDE and I'm sure Klipper was running. I'll try to retest with fedora core 7 (with and without Klipper) later today. I'm fine with leaving this WORKSFORME unless I find that Klipper's not to blame.
(In reply to comment #21) > (In reply to comment #19) > > It looks like the root cause of this bug was that people were running the > > Klipper Clipboard applet which was wreaking havoc with clipboard operations in > > Eclipse. > > Does this mean you just ignore this error? Did you opened a bug report on > Klipper to get this fixed? Sorry, I do not have the knowledge to write such a bugreport. How does Eclipse use the clipboard? Is it possible to write a trivial test program to check the copy&paste behaviour? Quoting http://www.kdedevelopers.org/node/1787: <quote> And, while Klipper and X clipboard in general used to have and still have some problems (what doesn't after all), many Klipper problems are actually caused by broken clipboard implementations in various applications including OpenOffice.org or Mozilla/Firefox or by the way X clipboard works and most Klipper hacks are there in order to work around such problems. </quote> Please note that identifying the Klipper relation doesn't ensure this is indeed a Klipper bug, right? It is a very distracting bug. Having a workaround (stopping Klipper) doesn't solve it ...
I can confirm that Klipper is the cause of the problem on my system, too. Gentoo with KDE 3.5.5 Eclipse 3.3 Sun JRE 1.6 However, I would support the remarks in comment #24 and reopen this bug (but I do not have the right). Disabling Klipper is a workaround and does not really solve the problem. Eclipse is - at least on my system - the only application that has problems with klipper/clipboard.
(In reply to comment #25) > However, I would support the remarks in comment #24 and reopen this bug (but Can you please vote on this bug so that it will indeed be fixed soon?
(In reply to comment #26) Added my vote.
(In reply to comment #25) I noticed this problem too (Gentoo, KDE 3.5.7, Eclipse 3.2), but I found that if I uncheck 'Prevent empty clipboard' in Klipper's settings, then copy/paste works correctly in Eclipse while Klipper is running.
(In reply to comment #28) > if I uncheck 'Prevent empty clipboard' in Klipper's settings I can confirm this. Unchecking this option fixes the problem.
Jens, do the steps in Comment #28 work for you?
(In reply to comment #30) > Jens, do the steps in Comment #28 work for you? Yes, this works. In 191665 I noticed that also keeping xclipboard open helps and that Eclipse 3.2 reacts differently than 3.3. But all these "solutions" are just ugly workarounds! There is either a bug in Eclipse or in klipper or in both.
Jepp, I prefer a "real" solutions too since closing klipper has other disadvantages I don't like so much..
*** Bug 198514 has been marked as a duplicate of this bug. ***
Have this bug too on (still) Eclipse-sdk-3.4-r2 on Gentoo in gnome. I've just disabled my Glipper (sort of Klipper for gnome) so will see what it gives. Had comment #17's warning as well. I know that Glipper is sort of getting deprecated quietly but does anyone have a similar hint for Glipper so I can keep it? Thanks to the devs and anyone involved in working this out.
(In reply to comment #34) > Have this bug too on (still) Eclipse-sdk-3.4-r2 on Gentoo in gnome. I've just > disabled my Glipper (sort of Klipper for gnome) so will see what it gives. Had > comment #17's warning as well. I know that Glipper is sort of getting > deprecated quietly but does anyone have a similar hint for Glipper so I can > keep it? > > Thanks to the devs and anyone involved in working this out. > Indeed, without Glipper I'm not seeing this any longer. Happy coding!
Also note that some reproducible scenarios got fixed for 3.4.1 (see bug 200743 and bug 243266).
Ok, it's a feature of running Klipper and people who run this thing see the problem. It was closed as WORKSFORME and really shouldn't have been. It might have been closed as WONTFIX (not much better, but captures the fact that we CANTFIX it). Why does Eclipse have this problem but other GTK applications to not? Also note that the bug may be fixed when the bugs in comment #36 were fixed.
(In reply to comment #36) > Also note that some reproducible scenarios got fixed for 3.4.1 (see bug 200743 > and bug 243266). The problem still exists in 3.4.1. Let me explain how I can reproduce it: cd /tmp tar xzf ~/eclipse-SDK-3.4.1-linux-gtk-x86_64.tar.gz rm -r workspace/ klipper & In klipper: Clear Clipboard history Configure klipper: [ ] Popup menu at mouse-cursor position [x] Save clipboard contents on exit [x] Remove whitespace when executing actions [ ] Replay actions on an item selected from history [X] Prevent empty clipboard <-- important for this bug! [ ] Ignore selection * Separate clipboard and selection Timeout for action popups: 8 sec Clipboard history size: 7 entries PS: I wonder why "Prevent empty clipboard" is important to reproduce this bug. Tooltip of this option: "Selecting this option has the affect, that the clipboard can never be emptied. E.g. when an application exists, the clipboard would usually be emptied." I don't need to stop Eclipse during the reproduction of this bug, I also do not manually clear the clipboard ... Eclipse: eclipse/eclipse & select new workspace Open file test.txt containing: line1 line2 line3 line4 (compare bug #191665). Following the recipe in bug #191665 the bug occurs often: bug occurred on attempt: 11, 4, 14, ... (less than one minute) This happens on a openSUSE 10.2 (X86-64) system using package kdebase3-3.5.5-102.11 (contains klipper). I tried the same on a remote host which has a newer KDE: Klipper from kdebase4-workspace-4.0.4-24.1 (openSuSE 11.0) (remote access, also Klipper was started remotely) doesn't has this problem (tried 100 times). Trying again with a local Klipper (from kdebase3-3.5.5-102.11) and the problem occurs again. So it maybe indeed a problem in Klipper? What versions are used by other reporters? Will try to get local access on the remote host and reproduce it there.
(In reply to comment #38) > Will try to get local access on the remote host and reproduce it there. I was lucky and got local access: Same problem, could be reproduced during seconds two times ...
* A workaround is not a solution: --------------------------------- I am using Klipper too and cannot even imagine to stop using it as my daily work is relying upon its presence for efficency. Neither can I switch off the "emptiness prevention" option. This ticket actually _is_ a bug and the fact that it shows itself only when Klipper is running around shows how the environment around eclipse is important to take into account. This, by no way, implies that this environment is the cause of the bug. It is understandable that it is not easy to solve, but I cannot agree that having a workaround is a good solution. * Proposal for a way to shoot this bug: --------------------------------------- 1 - Is someone here able to launch Klipper with debugging log level and use it to see what happens when the bug arises in eclipse ? If it doesn't give something interesting, use solution 2. 2 - Is someone able to run klipper in a debugger (KDevelop seems to _the_ KDE IDE with debugging support) and see what is does happen actually when the bug arises and what differs from the case where everything works well ? * When one of those 2 solutions will be tried will we will surely be closer to solve this nasty problem.
Kevin, this problem has been in Eclipse for a while and would be wonderful to fix, even if the fix is a workaround for something that Klipper is doing. Can take a look at this one?
related Glipper Bug http://sourceforge.net/tracker/?func=detail&aid=2159954&group_id=167085&atid=841538
I can't reproduce this bug running: kdm-kde4 4:4.0.3-0ubuntu2 klipper-kde4 4:4.0.3-0ubuntu2 libgtk2.0-0 2.12.9-3ubuntu5 and Eclipse I20090317-1745, . I'll try on Gnome with Glipper.
Gnome and Glipper are working fine for me as well. glipper 1.0-1ubuntu1 Could those of you still able to reproduce this, please update this bug report with your gtk version?
I considering closing this as WORKSFORME. Is anyone still having this problem? If this is still a problem for you, please update this PR with your gtk version ('rpm -q gtk2' or 'dpkg -l | grep gtk2').
Kevin, I simply cannot test with an unstable version of Eclipse. My versions of Klipper and gtk2 match yours. My version of Eclipse is 3.4.2 M20090211-1700 and the problem occurs. Just a proposal: Maybe you can try with the latest stable one and tell us if you find out some strange copy-paste behaviour this way ?
I still have this problem too. My gtk-Version is 2.14.7. KDE is in version 4.2.1 and I use the latest stable eclipse release.
tried again on a fedora box running KDE 4.2.1 and gkt 2.14.7 and the latest eclipse 3.5. Cut, Copy and paste are all working for me.
I've tried 3.4.2 as well, and cut/copy/paste from the menu and the keybindings. I haven't seen this yet. Is there anything special about the file that you're working on? Is it read only? On a network mounted drive? Are you using the java editor, or the text editor? Is there anything else that you can think of to help me replicate this problem?
Ok, quite astonishing ! Thank you for having tested so many configurations in a so short time ! Well, my use case : Eclipse Java EE perspective, Java editor (editing .java file). The file has nothing special: plain text file, UTF-8, stored on HDD, read-write mode, user owned, ... I think that the Java Editor _may_ be the real root of the problem if it has to be in the described context. Moreover, I can tell something about the bug (I am hoping some will confirm): it happens when there is some kind of pause done by the hands (I use keyboard a lot) during the selection. E.g you are at the end of a line containing an assignment with cast like the following : GenericType pojo = (GenericType)Builder.build( param1, param2); You start using CTRL-SHIFT-LEFT_ARROW to select previous token multiple times until your selection's start is after the '(', in one quick run (no pausing). You copy then paste on the line just above. You restart your selection: go to the end of the original line, using the same key combo, your go back to the start of the line, stopping just after the '(' while keeping the SHIFT key pressed. You wait maybe 1.5 seconds and then go on selecting until you have grabbed the 'pojo' word. Copy-paste anywhere : you don't have the text you selected. Ok, I have to say that it failed (i.e the bug occured) the first time I did it, bug worked the 5 next times I retried. It failed on the 6th attempt, starting from the beginning of the line and applying the same pausing principle. I hope it helps ! Michel
Ok, you can make it happen. Are you able to self hose and hack SWT and other places in Eclipse to see what is happening? Kevin can help you.
I can't promise any delay as this is the laptop for my job, but I am ready to try helping the best I can. What do I have to do first ? I'll have to download eclipse sources and the like and recompile it all by myself, I think. Doing so ! Michel
Instructions for running SWT from CVS are here: http://www.eclipse.org/swt/cvs.php
Created attachment 132437 [details] patch with println This patch adds some println logging to give us information of what is happening when data is put on and retrieved from the system clipboard. This output may be helpful in debugging this scenario. To run with the logging, please check out SWT from HEAD into an empty workspace (instructions in link above), apply the patch to org.eclipse.swt, launch your normal workspace as a new Eclipse Application launch configuration, and work in the target workspace until copy/paste fails for you, then append the output from the printlns here. I know this is a hassle, but until I have a way of reproducing this bug locally, I'm dependent on everyone else to provide as much information as possible.
I also have the copy/paste issue. My config: - Opensuse 11.1 - KDE 4.2.3 - Eclipse Version: 3.5.0 Build id: I20090313-0100 Like Michel said, I also have the feeling that this bug occurs more often when using the keyboard to do quick selection and cut/copy/paste. In some cases I even happen to cut some text, the text is gone, and when I paste I get a totally different content, and klipper also doesn't contain the text I just cut off. So I have to cancel (Ctrl+Z) and re-cut again, and hope it will work the second time.
*** Bug 277494 has been marked as a duplicate of this bug. ***
This is happening to me as well. It is very very disrupting. Eclipse Version: 3.4.2 Build id: M20090211-1700 GTK: libgtk2.0-0 2.16.1-0ubuntu2 KDE: 4.2.2 Klipper: 0.9.7 Linux Distro: Kubuntu 9.04 "Jaunty Jackalope" ctrl+c multiple times is the most effective workaround I've found. ctrl+x munches text without saving it (the horror!). I stay busy as a developer, but if I get a free afternoon I'll attempt to rebuild Eclipse with the logging patch to see if I can contribute here. Thanks.
OK, I finally was able to retest with the println patch. I used gain the example from comment 38 and noticed that whenever copying fails the last parameter is "false" as in <setData|transfer types[org.eclipse.swt.dnd.RTFTransfer,org.eclipse.swt.dnd.TextTransfer,]|clipboards=1|false> It may nevertheless be possible that it is (very rare) also false if it sometimes works indeed but it is at least a first point to start. Here is a attempt with 3 failures (including the last line): <setData|transfer types[org.eclipse.swt.dnd.TextTransfer,]|clipboards=2|true> <setData|transfer types[org.eclipse.swt.dnd.TextTransfer,]|clipboards=2|true> <setData|transfer types[org.eclipse.swt.dnd.TextTransfer,]|clipboards=2|true> <setData|transfer types[org.eclipse.swt.dnd.TextTransfer,]|clipboards=2|true> <getFunc|tdata.type[72]|tdata.format[8]|1> <setData|transfer types[org.eclipse.swt.dnd.RTFTransfer,org.eclipse.swt.dnd.TextTransfer,]|clipboards=1|true> <getFunc|tdata.type[72]|tdata.format[8]|1> <getFunc|tdata.type[72]|tdata.format[8]|1> <setData|transfer types[org.eclipse.swt.dnd.TextTransfer,]|clipboards=2|true> <setData|transfer types[org.eclipse.swt.dnd.TextTransfer,]|clipboards=2|true> <getFunc|tdata.type[72]|tdata.format[8]|1> <setData|transfer types[org.eclipse.swt.dnd.RTFTransfer,org.eclipse.swt.dnd.TextTransfer,]|clipboards=1|false> <setData|transfer types[org.eclipse.swt.dnd.TextTransfer,]|clipboards=2|true> <setData|transfer types[org.eclipse.swt.dnd.TextTransfer,]|clipboards=2|true> <getFunc|tdata.type[72]|tdata.format[8]|1> <setData|transfer types[org.eclipse.swt.dnd.RTFTransfer,org.eclipse.swt.dnd.TextTransfer,]|clipboards=1|true> <getFunc|tdata.type[72]|tdata.format[8]|1> <getFunc|tdata.type[72]|tdata.format[8]|1> <setData|transfer types[org.eclipse.swt.dnd.TextTransfer,]|clipboards=2|true> <setData|transfer types[org.eclipse.swt.dnd.TextTransfer,]|clipboards=2|true> <getFunc|tdata.type[72]|tdata.format[8]|1> <setData|transfer types[org.eclipse.swt.dnd.RTFTransfer,org.eclipse.swt.dnd.TextTransfer,]|clipboards=1|true> <getFunc|tdata.type[72]|tdata.format[8]|1> <getFunc|tdata.type[72]|tdata.format[8]|1> <setData|transfer types[org.eclipse.swt.dnd.TextTransfer,]|clipboards=2|true> <getFunc|tdata.type[72]|tdata.format[8]|1> <setData|transfer types[org.eclipse.swt.dnd.RTFTransfer,org.eclipse.swt.dnd.TextTransfer,]|clipboards=1|false> <setData|transfer types[org.eclipse.swt.dnd.TextTransfer,]|clipboards=2|true> <getFunc|tdata.type[72]|tdata.format[8]|1> <setData|transfer types[org.eclipse.swt.dnd.RTFTransfer,org.eclipse.swt.dnd.TextTransfer,]|clipboards=1|true> <getFunc|tdata.type[72]|tdata.format[8]|1> <getFunc|tdata.type[72]|tdata.format[8]|1> <setData|transfer types[org.eclipse.swt.dnd.TextTransfer,]|clipboards=2|true> <getFunc|tdata.type[72]|tdata.format[8]|1> <setData|transfer types[org.eclipse.swt.dnd.RTFTransfer,org.eclipse.swt.dnd.TextTransfer,]|clipboards=1|true> <getFunc|tdata.type[72]|tdata.format[8]|1> <getFunc|tdata.type[72]|tdata.format[8]|1> <setData|transfer types[org.eclipse.swt.dnd.TextTransfer,]|clipboards=2|true> <getFunc|tdata.type[72]|tdata.format[8]|1> <setData|transfer types[org.eclipse.swt.dnd.RTFTransfer,org.eclipse.swt.dnd.TextTransfer,]|clipboards=1|true> <getFunc|tdata.type[72]|tdata.format[8]|1> <getFunc|tdata.type[72]|tdata.format[8]|1> <setData|transfer types[org.eclipse.swt.dnd.TextTransfer,]|clipboards=2|true> <getFunc|tdata.type[72]|tdata.format[8]|1> <setData|transfer types[org.eclipse.swt.dnd.RTFTransfer,org.eclipse.swt.dnd.TextTransfer,]|clipboards=1|false> Another one: <setData|transfer types[org.eclipse.swt.dnd.TextTransfer,]|clipboards=2|true> <getFunc|tdata.type[72]|tdata.format[8]|1> <setData|transfer types[org.eclipse.swt.dnd.RTFTransfer,org.eclipse.swt.dnd.TextTransfer,]|clipboards=1|true> <getFunc|tdata.type[72]|tdata.format[8]|1> <getFunc|tdata.type[72]|tdata.format[8]|1> <setData|transfer types[org.eclipse.swt.dnd.TextTransfer,]|clipboards=2|true> <getFunc|tdata.type[72]|tdata.format[8]|1> <setData|transfer types[org.eclipse.swt.dnd.RTFTransfer,org.eclipse.swt.dnd.TextTransfer,]|clipboards=1|true> <setData|transfer types[org.eclipse.swt.dnd.TextTransfer,]|clipboards=2|true> <getFunc|tdata.type[72]|tdata.format[8]|1> <setData|transfer types[org.eclipse.swt.dnd.RTFTransfer,org.eclipse.swt.dnd.TextTransfer,]|clipboards=1|true> <getFunc|tdata.type[72]|tdata.format[8]|1> <getFunc|tdata.type[72]|tdata.format[8]|1> <setData|transfer types[org.eclipse.swt.dnd.TextTransfer,]|clipboards=2|true> <getFunc|tdata.type[72]|tdata.format[8]|1> <setData|transfer types[org.eclipse.swt.dnd.RTFTransfer,org.eclipse.swt.dnd.TextTransfer,]|clipboards=1|false> And a final one: <setData|transfer types[org.eclipse.swt.dnd.TextTransfer,]|clipboards=2|true> <getFunc|tdata.type[72]|tdata.format[8]|1> <setData|transfer types[org.eclipse.swt.dnd.RTFTransfer,org.eclipse.swt.dnd.TextTransfer,]|clipboards=1|true> <getFunc|tdata.type[72]|tdata.format[8]|1> <getFunc|tdata.type[72]|tdata.format[8]|1> <setData|transfer types[org.eclipse.swt.dnd.TextTransfer,]|clipboards=2|true> <setData|transfer types[org.eclipse.swt.dnd.TextTransfer,]|clipboards=2|true> <getFunc|tdata.type[72]|tdata.format[8]|1> <setData|transfer types[org.eclipse.swt.dnd.RTFTransfer,org.eclipse.swt.dnd.TextTransfer,]|clipboards=1|false> <setData|transfer types[org.eclipse.swt.dnd.TextTransfer,]|clipboards=2|true> <setData|transfer types[org.eclipse.swt.dnd.TextTransfer,]|clipboards=2|true> <getFunc|tdata.type[72]|tdata.format[8]|1> <setData|transfer types[org.eclipse.swt.dnd.RTFTransfer,org.eclipse.swt.dnd.TextTransfer,]|clipboards=1|true> <getFunc|tdata.type[72]|tdata.format[8]|1> <getFunc|tdata.type[72]|tdata.format[8]|1> <setData|transfer types[org.eclipse.swt.dnd.TextTransfer,]|clipboards=2|true> <setData|transfer types[org.eclipse.swt.dnd.TextTransfer,]|clipboards=2|true> <setData|transfer types[org.eclipse.swt.dnd.TextTransfer,]|clipboards=2|true> <setData|transfer types[org.eclipse.swt.dnd.TextTransfer,]|clipboards=2|true> <getFunc|tdata.type[72]|tdata.format[8]|1> <setData|transfer types[org.eclipse.swt.dnd.RTFTransfer,org.eclipse.swt.dnd.TextTransfer,]|clipboards=1|true> <getFunc|tdata.type[72]|tdata.format[8]|1> <getFunc|tdata.type[72]|tdata.format[8]|1> <setData|transfer types[org.eclipse.swt.dnd.TextTransfer,]|clipboards=2|true> <getFunc|tdata.type[72]|tdata.format[8]|1> <setData|transfer types[org.eclipse.swt.dnd.RTFTransfer,org.eclipse.swt.dnd.TextTransfer,]|clipboards=1|false> Klipper: 3.5.9 Eclipse: 3.4.2 Hope it helps, Jens
*** Bug 282886 has been marked as a duplicate of this bug. ***
I'm also experiencing the problem. KDE 4.3.0 (including klipper 4.3.0) gtk+ 2.16.5 Eclipse 3.5.0 sun jdk 1.6.15
I'm experiencing this problem. It's hard to not be able to use copy/paste and loss of data is possible when cutting. >>> please upgrade this bug for faster resolution (Critical, or P1) <<< I'm on Galileo, Arch Linux 64 bits, KDE 4.3, xorg server 1.6.3 java.version=1.6.0_14 java.vendor=Sun Microsystems Inc. BootLoader constants: OS=linux, ARCH=x86_64, WS=gtk, NL=en_US
(In reply to comment #61) > I'm experiencing this problem. It's hard to not be able to use copy/paste and > loss of data is possible when cutting. Do the workarounds of shutting down Klipper or unchecking the 'Prevent empty clipboard' options work for you?
Created attachment 147763 [details] Proposed Patch Upon investigating the problem, it appears that the Klipper claims the ownership of the clipboard when the paste fails. It is evident from the API gtk_clipboard_set_with_data() returning false every time it is unable to copy the data onto clipboard. The reason being - if the contents are set again (by the same app), then either we should explicitly clear the clipboard content and set the data, or gtk_clipboard_set_with_data() invokes the clearFunc to clear the clipboard first and then, the same API has to be called to set the contents. Currently, we clear the clipboard (if the clipboard contents are set earlier) and then, we set the clipboard content. At this instance, there is a race condition among Klipper and Eclipse between the time we clear the clipboard and set the contents (again). As soon as we clear the clipboard, Klipper is notified about the empty clipboard and thus, it peeps in immediately and tries to set it's top element onto the clipboard (as 'Prevent empty clipboard' is set). Essentially, in this race condition, Klipper will claim the ownership of clipboard (as it sets the top element) and thus, Eclipse is unable to set the contents successfully. The fix is to avoid clearing the clipboard and make a hack to allow XClipboard for clearing the content before the contents are set.
That sounds good! A very anoying bug will get eliminated soon. Will this patch find its way into the next update of eclipse?
Thanks for analysing this nasty bug. I nevertheless do not understand your comments well enough to determine, whether the bug is a klipper or a Eclipse one. Can you answer this? Do you just workaround a bug in Klipper? (In reply to comment #63) > Upon investigating the problem, it appears that the Klipper claims the > ownership of the clipboard when the paste fails. The paste into Eclipse or into Klipper fails? > It is evident from the API > gtk_clipboard_set_with_data() returning false every time it is unable to copy > the data onto clipboard. The reason being - if the contents are set again (by > the same app), What app, Klipper or Eclipse? ...
Praveen, Sorry my linux box is in an unhappy state right now so I haven't had a chance to run your patch yet. Looking at the doc for gtk_clipboard_clear (http://library.gnome.org/devel/gtk/stable/gtk-Clipboards.html#gtk-clipboard-clear), it states that we should only be clearing after we call set_with_data. Are we just calling clear at a bad time? Putting an empty string on the clipboard is a little bit different than clearing it and I'm wondering it we'll cause problems like enablement of paste actions when there's really nothing on the clipboard. There are other places that we call clear. Should we be protecting those calls somehow to ensure that we're only trying to clear clipboards that we own?
(In reply to comment #66) > Looking at the doc for gtk_clipboard_clear > (http://library.gnome.org/devel/gtk/stable/gtk-Clipboards.html#gtk-clipboard-clear), > it states that we should only be clearing after we call set_with_data. Are we > just calling clear at a bad time? Yes Kevin. We are just clearing the clipboard at the bad time. As soon as we clear the clipboard, Klipper is notified about the empty clipboard event. Then, it acquires the ownership of the clipboard by setting the top element (to prevent the empty clipboard) at the same time we try to set the data. Thus, we fail to set the data after clearing the clipboard. > Putting an empty string on the clipboard is a > little bit different than clearing it and I'm wondering it we'll cause problems > like enablement of paste actions when there's really nothing on the clipboard. We paste an empty string only just before we set *real* content onto the clipboard. So, there is no chance of enabling the paste actions of empty clipboard. Setting an empty string acts as a catalyst to clear the previous content (by XClipboard) and thus, enables setting the new content (without the need for clear function). I know it is sort of hack to make SWT owns the clipboard before/after setting the new content. I couldn't find any API to let us own the clipboard though we clear it. > There are other places that we call clear. Should we be protecting those calls > somehow to ensure that we're only trying to clear clipboards that we own? I think we can not really do much about it. If an application is intended to just clear the clipboard, then we can not own the clipboard. If an application clears at certain point of time and sets the data after a while, then it should be possible for the application to acquire back the ownership and set it's contents. Please suggest if there is any way to handle it better.
Praveen, can you try taking out the calls to gtk_clipboard_clear() instead of adding the empty string and see if that works?
Created attachment 149224 [details] Patch v02 The new patch makes use of the API gtk_clipboard_set_with_owner() when the app sets the data again. This API doesn't invoke clearFunc when the contents are set again and getFunc is sequentially called. So, there is no need of clearing the clipboard before the contents are set, thus avoiding Klipper claiming the ownership of the clipboard. Bogdan, Please review the patch and comment. Thanks.
*** Bug 291847 has been marked as a duplicate of this bug. ***
Praveen, the patch looks OK - you left an extra println in there ;) You are trying to force a different path through gtk_clipboard_set_contents by passing in an owner object - did you verify that this approach will work on all versions of GTK? Will it work on repeated calls?
(In reply to comment #71) > Praveen, the patch looks OK - you left an extra println in there ;) > > You are trying to force a different path through gtk_clipboard_set_contents by > passing in an owner object - did you verify that this approach will work on all > versions of GTK? Will it work on repeated calls? My apologies. I incidentally missed out removing out that debugging statement. The behaviour of the code on different old versions is random. It was working on a couple of old versions, but now it is failing randomly against another old versions. I feel there is some config issue on my machine. It worked well for the repeated calls with new GTK versions (>2.10). I will reconfirm with more testing against the old versions.
Created attachment 149903 [details] Patch v03 In the old GTK versions (<=2.8), there were unexpected failures while creating the object for widget type. So, the code changes are modified in order to create a compatible object (for all GTK versions) as clipboardOwner. I've tested the new patch against all the GTK versions and it is working for repeated calls as well. Please review and comment if I miss anything else. Thanks.
May I ask to back-port this to Eclipse 3.5.2 (SR2)?
(In reply to comment #74) > May I ask to back-port this to Eclipse 3.5.2 (SR2)? Alternatively, you could also provide a patch for 3.5.1 if this is feasible. Thanks, Jörg
I also habe the clipbord problem: Suse 10.3 Eclipse 3.5.1 + CDT, Mylyn, and more KDE 3.5 + Klipper I solve the problem if I either start xclipboard and leave it open OR configure Klipper to "Synchronize contents of clipboard and selection" instead of "Separate clipboard and selection". The other settings of klipper are left alone. For me, the problem was that every second copy operation did not work. Repeated pressing of Ctr-C or any invocation method in any text editor (not input field, there it works) did fail every second time _if_ the cursor location was changed in between. If selection stayed the same, repeaded invocation of copy command did _not_ work. Thomas
Praveen, we need to make sure that we don't leak the g_object you create for clipboard owner. It needs to disposed of in the dispose callback. Also, you are sure that the clearfunc will get called when we are no longer owning the clipboard? (ie. someone else tries to put something on the clipboard)
Created attachment 152127 [details] Patch v04 Thanks Bogdan for pointing out that - I have released the object in the dispose callback now. Adding to that, clearFunc is always called when we no longer owns the clipboard, due to someone claiming the ownership of clipboard.
Patch released > 20091113. Jörg, I would consider releasing this patch to 3.5.x but I'd like for people to give the fix a try out first. It will be available in next week's I build for people to try. Thanks!
(In reply to comment #79) > Patch released > 20091113. > > Jörg, I would consider releasing this patch to 3.5.x but I'd like for people to > give the fix a try out first. It will be available in next week's I build for > people to try. Thanks! Since we do not use weekly builds, a patch to 3.5.1 would be much appreciated. Otherwise, we just wait for SR2.
(In reply to comment #80) > > Since we do not use weekly builds, a patch to 3.5.1 would be much appreciated. > Otherwise, we just wait for SR2. J�rg, I think Bogdan is saying we need confirmation from people who have the problem that 1) it solves the problem and 2) that it doesn't make things worse before we consider releasing this to 3.5.x (the risk would be pretty high). PW
With the patch in the code, I realized that selecting text (either through mouse or keyboard) in StyledText through a snippet output errors in the console as : (SWT:27553): GLib-GObject-CRITICAL **: g_object_new: assertion `G_TYPE_IS_OBJECT (object_type)' failed (SWT:27553): Gtk-CRITICAL **: gtk_clipboard_set_with_owner: assertion `G_IS_OBJECT (owner)' failed However, the copy/paste works fine in the presence of Klipper as well. My mistake - I didn't encounter these errors earlier as I was majorily testing with the self-host eclipse instance. do we need to back out the changes now?
Patch reverted. Praveen to retest new patch and submit when ready.
Created attachment 152381 [details] Patch v05 The new patch makes use of API gtk_clipboard_set_with_owner only for setting the contents. This will avoid clearing off the contents when they are set again. However, the clearFunc is called when other app claims the clipboard. Tested the new code changes against various GTK versions for snippets, hosted eclipse, and verified that it works for the repeated calls. Thanks.
*** Bug 156459 has been marked as a duplicate of this bug. ***
*** Bug 226540 has been marked as a duplicate of this bug. ***
Patch released > 20100112.
Refer to http://techtavern.wordpress.com/2008/08/10/fixing-copy-paste-issues-on-eclipse-and-kde/ who did a good analysis of the problem and a workaround. A "sort-of-maintainer" of Klipper posted the following comment there: [quote] It is most probably because Eclipse is one of the programs that empties the clipboard before claiming it. If that is case, the best solution would be for Eclipse to stop doing that… at best, it is unnecessary chatter via. the X protocol. It might also introduce a race condition, especially in these multicore days, as you probably see with Klipper here. [/quote] Seems to fit the findings in the latest comments.
(In reply to comment #87) > Patch released > 20100112. Why is clipboardOwner static ? ClipboardProxy is a singleton, and you are already setting it to zero in dispose() - which is not static. And the other question is: why isn't clipboardOwner destroyed ? Does it crash if you do ?
Created attachment 156510 [details] Patch to remove (In reply to comment #89) > Why is clipboardOwner static ? Thanks Felipe for pointing this out. Initially when I was working on this patch, I need to create the clipboardOwner in the _getInstance() method due to which I have marked the member as Static. However due to further changes in my implementation, I had moved it as class member, but then missed to remove the modifier. > And the other question is: why isn't clipboardOwner destroyed ? Does it crash > if you do ? No, it didn't. May be, I tried to simulate the behavior of shellHandle in Shell class. I created a new patching including the suggested changes - tested to make sure it doesn't break the existing functionality. Please review it and comment if anything else is required.
(In reply to comment #90) Go for it, looks good. Just move clipboardOwner up with the rest of the instance vars.
> (In reply to comment #90) > Go for it, looks good. Just move clipboardOwner up with the rest of the > instance vars. Thanks Felipe! Modified the patch. Fixed > 20100121.
I had this problem on Linux with xfce and clipman applet. After removing that applet, it works again. Possibly could help somebody. Tricky is that other applications work good with this applet.
I've had this problem with Glipper enabled under Ubuntu. I use Glipper so heavily in wiki editing, I couldn't live without it. There were questions in this thread about whether this is an Eclipse issue or a *lipper issue. Now that this issue is understood, it appears that this is being fixed on the Eclipse side. However, I wanted to add a point about defensive programming. The worst failure mode was pressing CTRL-X, seeing a chunk of code disappear, then moving the cursor, pressing CTRL-V, and not seeing the vanished code rematerialize. Sometimes (I think if I pressed CTRL-S) not even CTRL-Z will recover my lost snippet. If possible (and it doesn't cause too much overhead) Eclipse should be programmed to check that the clipboard contains the copied text before Eclipse deletes the text in the local edit buffer. This would be a prudent defense against a variety of failed clipboard scenarios.
Sorry for generating two posts, but it just occurred to me that there could be more clipboard prudence on the *lipper side of the fence as well. The reason to filter empty items (in my understanding) is to prevent empty items from spamming your recall list. At empty item at the head of the recall queue is NOT a usability issue IMO. One slot can be sacrificed to emptiness. Perhaps the *lipper implementations should be filtering the empty item when the head element is pushed onto the recall stack, rather than messing with the head element directly, and eliciting race conditions.
*** Bug 261546 has been marked as a duplicate of this bug. ***
