Community
Participate
Working Groups
Build Identifier: Version: Indigo Service Release 1 Build id: 20110916-0149 Copy and paste is failing intermittently in the Eclipse editor. The current workaround is to first paste to UltraEdit, then copy and paste from UltraEdit back into the new location in Eclipse. I was using 3.7.0 since June and didn't ever notice the issue. I started using 3.7.1 last week and have become increasingly annoyed by this defect. The issue sounds very similar to this other defect that was supposedly fixed https://bugs.eclipse.org/bugs/show_bug.cgi?id=200743 Reproducible: Sometimes Steps to Reproduce: 1. Select text in Eclipse editor window. 2. CTRL+C or CTRL+X 3. Press Page Up or Page Down keys to move to another part of the editor. 4. CTRL+V. Expect: Pasted text appears in new location. Actual: Nothing appears in the new location; except maybe some white space I can't consistently reproduce the issue to confirm whether some white space is appearing but I seem to recall white space only appearing after typing CTRL+V.
Brian, are you working directly on the machine or via some remote software?
> 1. Select text in Eclipse editor window. In which editor do you see it?
(In reply to comment #1) > Brian, are you working directly on the machine or via some remote software? I'm working directly on the machine.
(In reply to comment #2) > > 1. Select text in Eclipse editor window. > In which editor do you see it? Java editor
Note that I have several plugins installed on top of the "Eclipse IDE for Java Developers": - Sonar http://docs.codehaus.org/display/SONAR/Sonar+Eclipse - Subversive - Knopflerfish http://www.knopflerfish.org/eclipse_plugin.html - Mantis bug tracker - m2e jaxb2 extension - http://bitstrings.github.com/m2e-connectors-p2/releases/ Also have an active Mylyn task.
(In reply to comment #5) > Note that I have several plugins installed on top of the "Eclipse IDE for Java > Developers": How often is it failing? Could you try the SDK download: http://download.eclipse.org/eclipse/downloads/drops/S-3.8M4-201112091447/index.php to verify whether this might be caused by an additional bundle?
(In reply to comment #6) > (In reply to comment #5) > > Note that I have several plugins installed on top of the "Eclipse IDE for Java > > Developers": > > How often is it failing? I experienced the problem 5 times last night and once this morning. Our dev team is in a bug fix phase, so I'm not spending lots of time writing code each day. Last night I was working on a defect for a couple of hours that involved almost continuous coding so that is when I noticed the problem the most. > Could you try the SDK download: > http://download.eclipse.org/eclipse/downloads/drops/S-3.8M4-201112091447/index.php > to verify whether this might be caused by an additional bundle? OK, I'll try to use the SDK a bit and see if the problem occurs.
One other detail, all my Eclipse projects were imported using m2e the maven for eclipse support. Our product consists of ~150 maven artifacts.
Since I reported this issue. I've experienced the copy/paste failure 2 more times. I haven't tried using the plain SDK yet because all our projects are Maven artifacts so the m2e plugin makes me more productive. We're working towards a big build this week, maybe on Monday I can try to setup the projects in the SDK.
I have experiencing the same problem with 4.2M5, but not with 3.7. I my case 3.7.1 appears to be working correctly as well. When the problem occurs it only appears to affects "CTRL-C" but not "CTRL-V". The problem showing signs of continuous degradation over a period of an hour.
I have this problem too on two different machines running 4.2M5 (and 4.2M4, I think, and maybe earlier). Both are Win7 SP1, one is 32-bit and one is 64-bit. I've definitely seen the problem with a stock "Eclipse IDE for Java Developers" and no add'l plugins. The issue seems to be that Copy via Ctrl-C doesn't always work, and when it starts failing, it fails often. Paste via Ctrl-V always works, it just pastes the previous clipboard contents. Copy via the right-click context menu always works, as does Cut via Ctrl-X. Hitting Ctrl-C two or three times sometimes helps for awhile, but eventually doesn't. I think I'm usually switching back and forth a lot between windows when it happens, but in such cases even copying and pasting in the same window fails. Ctrl-C works fine in other apps, so I don't think I have some other program interfering.
I've been experiencing this issue in Eclipse 4.1.2 on Windows and Eclipse 3.7.2 on Mac OS X. Ctrl+C doesn't always work; the subsequent paste either pastes nothing or the previous clipboard contents (if there was any and it was text) --- it's as if the copy command was just completely missed. The text editor seems responsive when the copy command is issued. Seems to happen more often if Eclipse is open for a while. Working on a pretty large project (hundreds of files).
Same issue with Version: 3.7.2 on Ubuntu Linux. Note right click copy is working, crtl C copy is not working at all.
Eclipse Version: 4.2.0 on Mac OS 10.6.8 Build id: I20120315-1300 Command-C, Command-V, and Command-X don't work. Apparently, only XML editor is affected; Java editor works fine. Right click copy, cut, and paste work fine. Unbind these keys from Preferences -> General -> Keys seem to solve the problem.
(In reply to comment #14) > Unbind these keys from Preferences -> General -> Keys seem to solve the > problem. Thanks for this. I applied this fix shortly after you posted it and have been using Eclipse all week, and it seems to have taken care of the problem for me. I seem to have this issue in the editor all the time (not just when using the XML editor). I unbound Ctrl+C and Ctrl+X (never had any trouble with "Paste").
Also experiencing the same issue. Only observed in XML files while developing Android so far, however.
The android problem is different, see bug 384665 PW
Hi Paul, Just to give some input, we've had a report on aptana studio regarding that too at: https://jira.appcelerator.org/browse/APSTUD-3061 and after investigating, the issue appears to be that the copy/paste action enabled asynchronously in the selection changed listener created at: org.eclipse.ui.texteditor.AbstractTextEditor.getSelectionChangedListener() So, we have changed the fSelectionChangedListener so that it does the update synchronously (see code below) and we've had no reports after that -- so, it seems this fix should be applied to Eclipse itself -- instead of doing our own hacky update of the private fSelectionChangedListener :) public void selectionChanged(SelectionChangedEvent event) { Display current = Display.getCurrent(); if (current != null) { // Don't execute asynchronously if we're in a thread that has a display. // Fix for: https://bugs.eclipse.org/bugs/show_bug.cgi?id=368354 (the rationale // is that the actions were not being enabled because they were previously // updated in an async call). // but just patching getSelectionChangedListener() properly. fRunnable.run(); } else { if (fDisplay == null) { fDisplay = getSite().getShell().getDisplay(); } fDisplay.asyncExec(fRunnable); } handleCursorPositionChanged(); }
I have this problem as well on my MacBook Pro. I have to press 'apple + c' several times before it will copy the selected text to my clipboard. I have the most recent Eclips with the most recent updates. I have the Aptana plugin and the Maven plugin.
Just to note, only the Aptana Studio 3 editors: PHP, ruby, javascript, css, html, coffescript -- excluding PyDev have the fix I mentioned above in place -- another note is that it's still not in an official release, only in the nightly build (or on 3.3.0 when it's released), so, if you're using one of those editors in the nightly build, please mention that in https://jira.appcelerator.org/browse/APSTUD-3061 -- otherwise, if you're using JDT, PyDev or some other non aptana studio editor, you'll have to wait until some eclipse committer picks up the fix I mentioned at: https://bugs.eclipse.org/bugs/show_bug.cgi?id=368354#c18 -- or compile eclipse yourself with that fix in place :)
Any chance of getting this fixed? It is incredibly frustrating to code with copy/paste only working sometimes. Whenever I run my unittests in the background, the CPU load gets fairly high, and as a result copy/paste is very unreliable. It's a daily pain that I have now had for years.
Niraj, can you please check whether this bug can be reproduced in Juno SR2 or Kepler? Thanks!
Just to note, to reproduce it in dev, simply put a breakpoint at org.eclipse.ui.texteditor.AbstractTextEditor.getSelectionChangedListener() in the part that does the updateSelectionDependentActions (so, this emulates a computer under a heavy load where the async calls takes longer to execute). I think that the solution explained in Comment 21 should work properly, so, the problem is mostly having someone with commit rights to fix it to not do the asynchronous update if already in an UI thread.
(In reply to Fabio Zadrozny from comment #24) > Just to note, to reproduce it in dev, simply put a breakpoint at > org.eclipse.ui.texteditor.AbstractTextEditor.getSelectionChangedListener() > in the part that does the updateSelectionDependentActions (so, this emulates > a computer under a heavy load where the async calls takes longer to execute). Fabio, I am not able to reproduce it using the breakpoint you mentioned, but maybe I missed the point. Could you please provide detailed instruction step by step how to reproduce it consistently? Thanks!
To reproduce you can comment out the updateSelectionDependentActions() in the fRunnable inside the org.eclipse.ui.texteditor.AbstractTextEditor.getSelectionChangedListener() (which is what would happen if you have too much processing and the call ends up taking longer to execute -- as it's called in an fDisplay.asyncExec and not directly, so, there's no real telling on how much time it'll take to actually execute).
My Ctrl-C hasn't worked since I moved to Kepler, although I'm using the Spring Tool Suite. I have both "Ctrl-C" and "Ctrl-Insert" bound to "Copy". Only the latter ever works, but even that sometimes fails to store to the clipboard, if I've inadvertently first pressed Ctrl-C. In that case, I have to re-select the region I want, and then pressing Ctrl-Insert usually works. I don't think I've ever seen Ctrl-V fail to paste what I have in the clipboard. I'm on STS 3.4.0, which I believe uses Eclipse 4.3.1, and on Windows Seven.
Hi, any plans on applying the fix I mentioned on Comment 18? Another option is making me a committer and I'll apply it myself :P Note that the fix I mentioned is active in Aptana Studio for a year and a half already: https://jira.appcelerator.org/browse/APSTUD-3061 and wasn't reopened (and it had a ton of comments too)... It's possible that there may be a new issue there (since that fix was based on an older version of Eclipse and there could be a new bug lurking around, but one thing I know is that the fix outlined is definitely a step in the right direction).
Hi Fabio Zadrozny, I just tried your fix(comment 18) but seems that it's not working, after applying the fix I tried: 1.- Copy text on one editor. 2.- Change to another editor. 3.- Return to the first editor. 4.- Paste copied text. But nothing happened. Debugging the code, it seems that the line: fDisplay.asyncExec(fRunnable); is never reached, any ideas? or could you provide more info about the fix? maybe I'm missing something, thanks.
(In reply to César Iván Orozco Cervantes from comment #29) > Hi Fabio Zadrozny, > > I just tried your fix(comment 18) but seems that it's not working, after > applying the fix I tried: > > 1.- Copy text on one editor. > 2.- Change to another editor. > 3.- Return to the first editor. > 4.- Paste copied text. > > But nothing happened. Debugging the code, it seems that the line: > > fDisplay.asyncExec(fRunnable); > > is never reached, any ideas? or could you provide more info about the fix? > maybe I'm missing something, thanks. Well, the whole point of the patch is that it should call fRunnable.run(); in the current thread and not asynchronously on the next UI cycle, so, in a debug session it should enter fRunnable.run() and update the actions based on the current selection right away... A question: without the patch things worked for you or they never work? Against which version are you testing?
Created attachment 240350 [details] Patch which makes the update of actions synchronous when a selection changes in the text editor. Note: Just tested the patch here (which I'm attaching) based on Eclipse 4.3.1 and it seems to work properly for me... to see it 'not working', after applying the patch remove the line 'fRunnable.run();' from the patch and the actions should stop being updated (which is what currently happens when we have a busy cpu and it's updated asynchronously). i.e.: if you pressed Ctrl+C and had a busy cpu the copy action would be disabled at the time of the Ctrl+C (it could end up being enabled later on as the update is asynchronous, but you'd already have lost the copy at that point -- which is why it works sometimes and fails to work on others).
(In reply to Fabio Zadrozny from comment #30) > Well, the whole point of the patch is that it should call fRunnable.run(); > in the current thread and not asynchronously on the next UI cycle, so, in a > debug session it should enter fRunnable.run() and update the actions based > on the current selection right away... A question: without the patch things > worked for you or they never work? Against which version are you testing? Hi, about your questions, I always see the problem with and without the patch, the Eclipse I'm using is 3.6.2.5
(In reply to César Iván Orozco Cervantes from comment #32) > (In reply to Fabio Zadrozny from comment #30) > > Well, the whole point of the patch is that it should call fRunnable.run(); > > in the current thread and not asynchronously on the next UI cycle, so, in a > > debug session it should enter fRunnable.run() and update the actions based > > on the current selection right away... A question: without the patch things > > worked for you or they never work? Against which version are you testing? > > Hi, about your questions, I always see the problem with and without the > patch, the Eclipse I'm using is 3.6.2.5 Well, you may have a different version of the bug then :) Try putting the breakpoint on fRunnable.run() and stepping in to see why it's not enabling the copy action at that point... Still, note that the patch is still valid for the case where the copy usually works but doesn't under heavy cpu load.
(In reply to Fabio Zadrozny from comment #31) > Created attachment 240350 [details] > Patch which makes the update of actions synchronous when a selection changes > in the text editor. > > Note: Just tested the patch here (which I'm attaching) based on Eclipse > 4.3.1 and it seems to work properly for me... to see it 'not working', after > applying the patch remove the line 'fRunnable.run();' from the patch and the > actions should stop being updated (which is what currently happens when we > have a busy cpu and it's updated asynchronously). > > i.e.: if you pressed Ctrl+C and had a busy cpu the copy action would be > disabled at the time of the Ctrl+C (it could end up being enabled later on > as the update is asynchronous, but you'd already have lost the copy at that > point -- which is why it works sometimes and fails to work on others). Fabio, can you convert the patch into a Gerrit review? See http://www.vogella.com/tutorials/EclipsePlatformDevelopment/article.html#eclipsegerritcontribution
(In reply to Lars Vogel from comment #34) > Fabio, can you convert the patch into a Gerrit review? See > http://www.vogella.com/tutorials/EclipsePlatformDevelopment/article. > html#eclipsegerritcontribution Wait, I'm unable to reproduce this issue with Eclipse Luna M6. Can someone test with M6 and see if the problem still exists?
How are you checking? If you comment out line 3150: fDisplay.asyncExec(fRunnable); -- which is what could happen if you have a really busy cpu -- especially on lower end hardware, don't you have the issue? (if that's the case that 'fDisplay.asyncExec(fRunnable);' could be removed altogether...). Note that what I'm addressing here is a racing condition (which can be hard to reproduce, so, the general idea on commenting out the fDisplay.asyncExec(fRunnable); is that as its asynchronous you don't have guarantees on how long it'll take to happen -- sure, 'never' may be a really long time, but for simulating the bug it should suffice).
Or, if you want to reproduce closer to a 'real world' scenario, you can make a timer which will call the asyncExec after 2 seconds... and then see if copy/paste are always responsive.
Wow, that code is doubly broken! Thanks Fabio for finding the right spot! I've fixed it a bit differently: In order to actually work at all when not called from the UI thread, the #handleCursorPositionChanged(); also has to go into the runnable and to preserve existing call sequence it needs to be before updating the actions. Since we're already in M7, I'll keep the code for the non-UI thread, but during 4.5 I'll remove the whole runnable and asyncExec code. Fixed with http://git.eclipse.org/c/platform/eclipse.platform.text.git/commit/?id=0f77e7352f60dd8484b68b33ad3c150b8b079821
Backported to 3.6.2+.
*** Bug 338242 has been marked as a duplicate of this bug. ***
The fix (correctly) revealed bug 434791.
Is this actually fixed? I experienced a paste bug in Eclipse Luna 4.4 that shows a "No matches found" pop-up using: 1. Edit > Paste menu 2. Ctrl+V key but not when using right click > Paste. Screencast here: http://youtu.be/gubbMankxb0 Is this a different bug or this bug? If different then I'll file a new bug.
BTW, 1. Edit > Cut / Edit > Copy 2. Ctrl+X / Ctrl+C also doesn't work. (has no effect) However, right click > Cut and right click > Copy works.
(In reply to Hendy Irawan from comment #42) > Is this actually fixed? > > I experienced a paste bug in Eclipse Luna 4.4 that shows a "No matches > found" pop-up using: This pop-up is not coming from "us". You probably have some other plug-ins installed that cause this. Copy/Paste works fine for me in our Luna SDK: http://download.eclipse.org/eclipse/downloads/drops4/R-4.4-201406061215/
To anyone experiencing the same issue as me, Preferences > General > Keys > Restore Defaults made the issue go away. Also, I am using an upgraded workspace previously used by Eclipse Kepler 4.3.
I also have the problem with latest Eclipse Luna. I am running Eclipse J2EE without any additional plugin. I re-downloaded Eclipse, cleaned .metadata/ but same problem. After a few minutes I lose the copy/paste.
I confirm this problem with Eclipse Version: Luna Release (4.4.0) Build id: 20140612-0600 in SQL editor of DBeaver 3.0.0. Other editors are not affected.
This fix breaks some actions that listen to selection events and assume AbstractTextEditor#updateSelectionDependentActions() is asynchronous. Example: In older releases (e.g. in 4.3.2 or 4.4 M6 I20140306-1200), I could: - select some source in a Java editor - Source > Add Block Comment (Ctrl+Shift+/) - Source > Remove Block Comment (Ctrl+Shift+\) - Source > Add Block Comment (Ctrl+Shift+/) Starting from 4.4 M7, the "Add Block Comment" is disabled after the first invocation. The problem is that AddBlockCommentAction's update() method is now called too early and we run into StyledText bug 448762: When the RemoveBlockCommentAction modifies the document, this triggers a selection change event, but that event reports a zero-length selection. The selection gets corrected immediately after the event is sent, but there's no new event for that. With the async updating of the action, the SWT bug was not visible (since actions have to get the selection by themselves -- at a time when it's already correct). It's hard to say how many actions other than the Java "Add Block Comment" are affected by this concrete problem. I didn't find any severe issues in the Eclipse SDK. However, the Copy and Cut actions are also disabled after "Remove Block Comment", and they only don't fail because they fall back to the default implementations in the StyledText widget.
The Ctrl-C shortcut still does not work sometimes in Eclipse Mars 20141002-0151 and in Eclipse Luna 20140925-1800, the clipboard is empty after ctrl-c. It works fine in Eclipse Kepler 20140224-0627. Unfortunately I am not able to give you steps to reproduce empty clipboard right now. The bug is so annoying that I am still using Eclipse Kepler. I can give you steps to reproduce when ctrl-c does not work, but in a slightly different way - the old value remains in a clipboard. The steps are: in Java->Editor->Save actions switch on format source code, perform additional actions on save. In any Java file place braces differently so the formatting is needed, but do not save the file, then select some java code in the same file, then click as fast as you can ctrl-s and ctrl-c. The text usually is not copied. One more bug in Eclipse Luna and Mars is that in Save action when you check Correct indentation, the save action changes incorrectly braces in try-with-resource clause (when the brace is in a new line and a formatter is switched on in save actions). The workaround is to switch off correct indentation (indentation is still corrected because formatter is used in save actions).
I just experienced this bug on Windows7 x64 with: Version: Mars.2 Release (4.5.2) Build id: 20160218-0600 (I had to type these details as I could not copy&paste them here). I also restarted Eclipse with no change on the problem. Ctrl-X behaves like delete and Ctrl-V and Ctrl-C have no effect anymore. It is impossible to work with Eclipse effectively anymore. Regular copy&paste in other windows applications still work (I also had a general breakage of Windows clipboard a longer time ago) so this is really a problem in Eclipse. I worked with the same version of this Eclipse binary for many months without this problem and today it appeared out of nowhere. Nothing in error log when I do copy&paste - it just has no effect anymore. I will try if I can also reproduce this Bug with Neon.
(In reply to Jörg Hohwiller from comment #50) > I just experienced this bug on Windows7 x64 with: > > Version: Mars.2 Release (4.5.2) > Build id: 20160218-0600 > > (I had to type these details as I could not copy&paste them here). > > I also restarted Eclipse with no change on the problem. > Ctrl-X behaves like delete and Ctrl-V and Ctrl-C have no effect anymore. It > is impossible to work with Eclipse effectively anymore. > > Regular copy&paste in other windows applications still work (I also had a > general breakage of Windows clipboard a longer time ago) so this is really a > problem in Eclipse. > > I worked with the same version of this Eclipse binary for many months > without this problem and today it appeared out of nowhere. Nothing in error > log when I do copy&paste - it just has no effect anymore. > > I will try if I can also reproduce this Bug with Neon. By all means, open a new bug report with the steps. This one is considered fixed.
> By all means, open a new bug report with the steps. This one is considered fixed. Sorry for spam. While doing more analysis and trying to reproduce I discovered that is was still a windows and not an eclipse bug. I was only confused that C&P worked in other tools such as notepad or notepad++. So no bug here.
(In reply to Jörg Hohwiller from comment #52) > > By all means, open a new bug report with the steps. This one is considered fixed. > > Sorry for spam. np > While doing more analysis and trying to reproduce I > discovered that is was still a windows and not an eclipse bug. I was only > confused that C&P worked in other tools such as notepad or notepad++. So no > bug here. Do you have more details on that specific Windows bug?
