Community
Participate
Working Groups
Build Identifier: 20120614-1722 Since I switched from Eclipse 3.6.2 to 4.2, I've had problems with keyboard shortcuts being ignored by Eclipse. I have not been able to find a condition under which this can be consistently reproduced, but I suspect that it happens more often (though not always) when the UI blocks. This behavior is especially problematic for the copy+paste shortcuts. It effectively breaks copying to clipboard because it is more efficient to cut the text and paste it back so I have confirmation that the text was actually copied, instead of unsuccessfully trying to copy it two or three times, pasting the wrong text every time. Also, because Eclipse often isn't very responsive, I got used to marking, copying and pasting text before Eclipse is able to render the selection. In 3.6.2, this worked without problems, but now I have to wait until I selected and cut the text. That way, Eclipse's unresponsiveness becomes even more annoying. Might this be some race condition? Maybe the Ctrl+C shortcut is processed before the text selection is registered, so there is no selection to copy? I didn't mark the bug as major because there is this workaround, but I also didn't want to mark it as minor because it impedes work efficiency. Reproducible: Sometimes Steps to Reproduce: This bug happens very often during work, but I can't reproduce it in a repeatable manner.
Also see bug 70077, bug 200743 and bug 374036.
Does generally happen in while editing in editors(if so, java xml or other) or also dialogs, forms etc?
Lately, I've mostly been editing Latex files in the Texlipse editor (http://texlipse.sourceforge.net). I haven't noticed any similar problems in dialogs - I think the problem is limited to editors, but I can't tell for sure because I hardly use any dialogs except the "Find". But the find dialog is much more responsive than the editor, so if it is a race condition, maybe it just doesn't usually occur.
I've tried reproducing this in JDT, but it doesn't happen - but JDT is very responsive on my computer. I think this happens more often, though not always, when there is Texlipse's "Update" task running in the background. I'm not entirely sure that this is an UI bug, but I think that this is more likely because I think that if I press Ctrl+C and then Ctrl+V and nothing else in between, either both should be processed or none. Currently, however, it happens that Ctrl+V is processed without processing Ctrl+C. BTW. I am assuming that shortcut handling and copy+paste in editors is part of the UI, not of JDT/Texlipse/etc. - is this correct?
(In reply to comment #4) > > BTW. I am assuming that shortcut handling and copy+paste in editors is part of > the UI, not of JDT/Texlipse/etc. - is this correct? the platform handles the processing of the SWT.KeyDown for the keys, but after looking up the copy command delegates it to a contributed handler. Each editor supplies its own handlers for copy and paste. A quick check of the TexEditor source seems to indicate that it subclasses and uses the standard TextEditor (just as the java editor does). I'll have to do some more investigation. PW
(In reply to comment #5) > (In reply to comment #4) > Each editor supplies its own handlers for copy and paste. A quick check of the > TexEditor source seems to indicate that it subclasses and uses the standard > TextEditor (just as the java editor does). Maybe this is caused by the automatic parsing feature of Texlipse, which enables frequent parsing even before the user saves the currently edited file. http://sourceforge.net/tracker/?func=detail&aid=3508649&group_id=133306&atid=726818 I have turned that feature off a few minutes ago, and until since then, the copy+paste hasn't occurred. If it keeps working, does this mean that it's a Texlipse bug (e.g. a missing "synchronized") or might it still be a general problem in the UI that doesn't occur very often because most of the time the UI thread isn't used for expensive tasks? Bernhard Stadler
If it helps diagnose the problem, I'm seeing this strange kind of behaviour too editing xml files using 4.2 Classic and the Android ADT. For example, when trying to paste Ctrl-V in the current xml file either nothing happens or the paste is performed on the source file - which is not longer active and is hidden. Other keys, such as Del, fail to work too.
Oh, the ADT problem is slightly different: http://code.google.com/p/android/issues/detail?id=34630 PW
(In reply to comment #8) > Oh, the ADT problem is slightly different: > http://code.google.com/p/android/issues/detail?id=34630 > > PW Ah yes, apologies, just saw the ADT 34630 bug report.
Hi, I am also facing a lot of problems regarding the keyboard shortcuts. The issue is intermittent and all of a sudden most of the key board shortcuts(specifically f3, ctrl+D, ctrl+O ) stop working unless I restart my IDE.
I also have problems with shortcut keys after a couple of hours use. I have found that the shortcut keys are being actioned but in a tab I was previously working with, so to me it looks like the keys aren't working because they have no effect on the code I am looking at, but then if I switch back through my editor tabs I find with Ctrl-D for example the last line of code I edited in an older tab has been deleted. To get the shortcuts to action on the correct editor I have to find the tab that is taking the action and give it focus then go back to the editor I actually want to work with, and this time the shortcut keys switch with the tab and are actioned correctly.
(In reply to comment #11) > I also have problems with shortcut keys after a couple of hours use. Martyn, I believe that's bug 394517 PW
Hello, I have the same probleme with the "ctrl s" (Save) "Suppr" (delete) keys while editing java files. Note that the save option is desactivated in the "File" menu. (This legitimate the "Ctrl s" not working). Note that it seems that Eclipse messed up in multiple tabs seems to be the good option: If I try "Save as" option in the menu, I have the message "The file xxxxx already exists. Do you want to replace the existing file" Where xxxxx is the file openned in another tab. My configuration: Eclipse SDK Version: 4.2.2 Build id: M20130204-1200 Pluggins: WTP 3.4.0 EMF 2.8.3 Mylyn 1.0.4 / 3.8.4 AspectJ 1.7.3 Subversion client 1.8.6 M2E 1.3.1 CheckStyle 5.6.0 Findbugs 2.0.2
I am also getting this behavior in BuildId: 20130225-0426 on Mac-Mavericks. Command-S stops working. menu grayed out. Shift-Command-S works. Many other shortcuts also don't work, like Fn-F3, and many times, but not always Command-Z (undo).
I am also getting this with in my editor after working for a while and opening other file types like java, css and HTML the shortcuts stop working. The Global Action Handler that I added to StyledText and Text swt controls so that he ctl copy/paste/delete/undo keys would work in them allowed them to call our actions. These have been working fine since eclipse 3.2 and work fine in 3.6.2 but have changed to intermittently working since 4.2.2. This seems to be related to changes in the 4.0 versions ans is very aggravating to our users that edit code and html snippets in the controls.
I'm also running into this issue with the Eclipse CDT editor, build id: 20140925-1800. Specifically, the ctrl+s, ctrl+z shortcuts and delete and F3 keys stop working, amongst others. It seems to only happen with one specific file at a time, and if I close the file and re-open it then the issues stop (temporarily, anyways). I haven't figured out any way to reproduce it either. I did try setting -XX:MaxPermSize=512m and -Xmx1024m/-Xmx1536m in case it was related to a memory leak but that didn't help.
Hi Dan, Is there any exception or error in a log file (<WORKSPACE>/.metadata/.log)? If yes, could you attach the file?
Created attachment 247981 [details] Metadata log
Hi Wojciech, Yes, there are errors in the log. They seem similar to the ones from these two bugs: https://bugs.eclipse.org/bugs/show_bug.cgi?id=328808 https://bugs.eclipse.org/bugs/show_bug.cgi?id=413410 This exception was also output a few times in stderr, but I'm not sure if it's related: java.lang.InterruptedException at java.lang.Object.wait(Native Method) at org.eclipse.core.internal.jobs.Semaphore.acquire(Semaphore.java:39) at org.eclipse.core.internal.jobs.JobManager.join(JobManager.java:861) at org.eclipse.core.internal.jobs.InternalJob.join(InternalJob.java:384) at org.eclipse.core.runtime.jobs.Job.join(Job.java:420) at org.eclipse.linuxtools.internal.cdt.libhover.LibHover.getFunctionInfo(LibHover.java:390) at org.eclipse.cdt.internal.ui.text.CHelpSettings.getFunctionInfo(CHelpSettings.java:121) at org.eclipse.cdt.internal.ui.CHelpProviderManager.getFunctionInfo(CHelpProviderManager.java:163) at org.eclipse.cdt.internal.ui.text.c.hover.CDocHover.getHoverInfo(CDocHover.java:81) at org.eclipse.cdt.internal.ui.text.c.hover.AbstractCEditorTextHover.getHoverInfo2(AbstractCEditorTextHover.java:84) at org.eclipse.cdt.internal.ui.text.c.hover.BestMatchHover.getHoverInfo2(BestMatchHover.java:144) at org.eclipse.cdt.internal.ui.text.c.hover.CEditorTextHoverProxy.getHoverInfo2(CEditorTextHoverProxy.java:84) at org.eclipse.jface.text.TextViewerHoverManager$4.run(TextViewerHoverManager.java:166)
Actually, I seem to be able to reproduce this through Source -> Implement Method..: 1. Define a new function i.e. void foo(); 2. Source -> Implement Method... and select the new function. 3. The new function appears in the source, but various shortcuts do not work (F3, Ctrl+C,S,V,Z etc.). Previously I thought that the window needed to be closed to resolve the issue, but actually just switching to a different file in the editor and back is sufficient.
Thank you for the scenario. Unfortunately, so far I didn't manage to reproduce the issue following these steps. When reproducing the issue, does Eclipse log any new error or exception?
I have the same problem on Eclipse Luna CDT (4.4.1) running on Ubuntu 12.04. Behavior is very much as discribed by Dan T earlier https://bugs.eclipse.org/bugs/show_bug.cgi?id=385278#c16
I have the same problem on Eclipse Luna CDT (4.4.1) running on OpenSuse 12.2 using JDK 1.7 or 1.8.
(In reply to Wojciech Sudol from comment #21) > Thank you for the scenario. Unfortunately, so far I didn't manage to > reproduce the issue following these steps. > When reproducing the issue, does Eclipse log any new error or exception? Hi Wojciech, I actually did not experienced this bug again until yesterday. Nothing in particular seemed to trigger it, and I saw no messages in the logs after it occurred. Today, it happened again after using source->implement method in a header file. I was given a warning about a syntax error, and when I opened the cpp file, the delete key and various ctrl+ shortcuts were not working, as described before. The only messages in the log I could find came a few minutes before this happened: !SUBENTRY 1 org.eclipse.jface 2 0 2014-10-30 10:52:08.034 !MESSAGE A conflict occurred for CTRL+G: Binding(CTRL+G, ParameterizedCommand(Command(org.eclipse.cdt.ui.search.finddecl,Declaration, Searches for declarations of the selected element in the workspace, Category(org.eclipse.cdt.ui.category.source,Source,Source commands,true), org.eclipse.ui.internal.WorkbenchHandlerServiceHandler@29f71155, ,,true),null), org.eclipse.ui.defaultAcceleratorConfiguration, org.eclipse.cdt.ui.cEditorScope,,,system) Binding(CTRL+G, ParameterizedCommand(Command(org.eclipse.cdt.ui.search.finddecl,Declaration, Searches for declarations of the selected element in the workspace, Category(org.eclipse.cdt.ui.category.source,Source,Source commands,true), org.eclipse.ui.internal.WorkbenchHandlerServiceHandler@29f71155, ,,true),null), org.eclipse.ui.defaultAcceleratorConfiguration, org.eclipse.cdt.ui.cViewScope,,,system) !SUBENTRY 1 org.eclipse.jface 2 0 2014-10-30 10:52:08.034 !MESSAGE A conflict occurred for CTRL+SHIFT+G: Binding(CTRL+SHIFT+G, ParameterizedCommand(Command(org.eclipse.cdt.ui.search.findrefs,References, Searches for references to the selected element in the workspace, Category(org.eclipse.cdt.ui.category.source,Source,Source commands,true), org.eclipse.ui.internal.WorkbenchHandlerServiceHandler@1b92f8f9, ,,true),null), org.eclipse.ui.defaultAcceleratorConfiguration, org.eclipse.cdt.ui.cEditorScope,,,system) Binding(CTRL+SHIFT+G, ParameterizedCommand(Command(org.eclipse.cdt.ui.search.findrefs,References, Searches for references to the selected element in the workspace, Category(org.eclipse.cdt.ui.category.source,Source,Source commands,true), org.eclipse.ui.internal.WorkbenchHandlerServiceHandler@1b92f8f9, ,,true),null), org.eclipse.ui.defaultAcceleratorConfiguration, org.eclipse.cdt.ui.cViewScope,,,system) There are a few more similar messages for other shortcuts, but curiously, none for some of the shortcuts that were disabled like ctrl+s, ctrl+c, ctrl+v, etc. Unfortunately, I can't seem to reproduce the bug until after it happens once - I haven't found any way to trigger it.
Hi Dan, This logs are caused by bug 413410, and most likely are not related to this issue.
I'm also having this issue on Eclipse Luna Service Release 1 (4.4.1) Build id: 20140925-1800, running on Windows 7. It happens intermittently and the shortcuts only work again after I close and reopen eclipse. Reopening a file or changing tabs didn't work for me. As the informations provided thus far weren't enough to find the reason this bug happens, some other details that might help: - I use the dark skin of eclipse, although I don't think it should be a problem - It seems to happen after I close all files and open a file using Open Resource (ctrl+shift+r) - Most ctrl+[key] shortcuts don't work, but ctrl+shift+[key] shortcuts seem to work fine. - The same problem occour on a lot of editors. It happened to me using both java, xml and html editors.
Whenever this happens to me, I notice that if I go into Preferences -> General -> Keys and delete all the duplicate shortcut key bindings (even if they're for totally different scopes) such that there's only one left (e.g. "In Windows") then that key magically starts working again.
I opened "package explorer" view, and activated the "Link with editor" toogle. After this the problem seems to have stopped happening.
Same here, almost always happens after some time, the delete key fails as well. Version: Luna Service Release 1a (4.4.1) Build id: 20150109-0600 Linux X86_64
I've had the same problem, Ctrl+S among others didn't work, right-clicking on a file in the Package Explorer didn't work either. After restarting Eclipse with "-clean" it started to work again.
Same here. Eclipse Luna, Windows 8.1, Javascript Project. Altough i'm using Visual Studio key bindings, there are shortcuts shared by both settings, like Ctrl+Shift+[Arrow]. When these common shortcuts stop working I've noticed active key bindings are the ones by default, not VS. Nevertheless, preference window shows VS as active. Restarting Eclipse always solves the problem.
WORKAROUND: I have the same Problem but also a solution which does not require a restart of eclipse and might get you on track to find the source of the problem: It happens in the editor in Kepler that the Ctrl key stops working: Version: Kepler Service Release 1 Build id: 20130919-0819 This is how I could reproduce this bug: 1) Edit a new java class and add some java code: Integer test; test. 2) after this dot window with choices is opened. 3) Select one method (e.g. valueOf). 4) A yellow window is opened with hints 5) Klick in this window 6) Use ESC or click in the editor to continue. Ctrl+S etc will not work. How to make it work again: a) Use autocompletion to get this yellow hint window. b) Click in that window and press Ctrl c) Use ESC or click in the editor to continue Ctrl works again.
The same problem. I had never notice any problems when i worked with one display connected to my PC. But when i had plugged the second display it started to happen. Version: Luna Service Release 1a (4.4.1) Ubuntu 14.04
I can confirm that I have a two monitor setup here where the problem occurs.
I have one monitor and the problem still occurs.
*** Bug 469751 has been marked as a duplicate of this bug. ***
My keybindings stop working very quickly. Swithing to another file and back again usually fixes it for a short while. The rate at which it happens seems to vary on different projects I work on - they differ on jdk being used 1.6 or 1.7, multiple monitors or not, heavy debugging with tons of breakspoints or not. Using ubtuntu 12.04, eclipse luna 4.4.1.
Created attachment 257692 [details] Eclipse crash log Nothing in the .metadata log to suggest what is wrong but if I keep using eclipse despite the shortcuts coming and going then eventually eclipse crashes with JVM logfiles like the one I attached here.
I had the same problem on Ubuntu using Mars but it was completely resolved with upgrade to Ubuntu 16.04 LTS.
I use Eclipse Oxygen for a couple of weeks and first experienced this today.
Same problem with Ctrl+3 for toggle comment (python) When restart work again. Debian Stretch Eclipse: Version: Oxygen.3a (4.7.3a) Build id: M20180330-0640
As far as I understand we can see what is currently binded in the '.metadata\.plugins\org.eclipse.e4.workbench\workbench.xmi' file. I indeed see my lost "SHIFT+F10" shortcut there pointed to the command="_tBD5sVrBEem2T6E-rHCVPA". The problem is there are two definitions of this command: <commands xmi:id="_tBD5SVrBEem2T6E-rHCVPA" elementId="org.eclipse.mylyn.tasks.ui.command.previousTask" <commands xmi:id="_tBD5sVrBEem2T6E-rHCVPA" elementId="org.eclipse.debug.ui.commands.RunLast" Overall the xml:id generation rule looks a bit weird: xmi:id="_tBD5SFrBEem2T6E-rHCVPA" xmi:id="_tBD5SVrBEem2T6E-rHCVPA" xmi:id="_tBD5SlrBEem2T6E-rHCVPA" xmi:id="_tBD5S1rBEem2T6E-rHCVPA" F->V->l->1 ? So my suspicion is that the hotkey is not lost but points to the random different command due to wrong ids. xmi:id="_tBD5ZFrBEem2T6E-rHCVPA" xmi:id="_tBD5ZVrBEem2T6E-rHCVPA" xmi:id="_tBD5ZlrBEem2T6E-rHCVPA" xmi:id="_tBD5Z1rBEem2T6E-rHCVPA" xmi:id="_tBD5aFrBEem2T6E-rHCVPA" xmi:id="_tBD5aVrBEem2T6E-rHCVPA" xmi:id="_tBD5alrBEem2T6E-rHCVPA" xmi:id="_tBD5a1rBEem2T6E-rHCVPA" xmi:id="_tBD5bFrBEem2T6E-rHCVPA" I have 942 commands defined in the workbench.xml. But if I spotted the rule correctly (6th letter a-zA-z and four different letters next) we can have commands only for 8 English alphabets :) I also noticed that xml:id are re-generated during restart. That might explain why the problem suddenly appears. Used Eclipse for RCP and RAP Version: 2018-12 with IntelliJ IDEA keymap plugin.
(In reply to Andrei Baleska from comment #42) > As far as I understand we can see what is currently binded in the > '.metadata\.plugins\org.eclipse.e4.workbench\workbench.xmi' file. > > I indeed see my lost "SHIFT+F10" shortcut there pointed to the > command="_tBD5sVrBEem2T6E-rHCVPA". The problem is there are two definitions > of this command: > > <commands xmi:id="_tBD5SVrBEem2T6E-rHCVPA" > elementId="org.eclipse.mylyn.tasks.ui.command.previousTask" > <commands xmi:id="_tBD5sVrBEem2T6E-rHCVPA" > elementId="org.eclipse.debug.ui.commands.RunLast" > > Overall the xml:id generation rule looks a bit weird: > > xmi:id="_tBD5SFrBEem2T6E-rHCVPA" > xmi:id="_tBD5SVrBEem2T6E-rHCVPA" > xmi:id="_tBD5SlrBEem2T6E-rHCVPA" > xmi:id="_tBD5S1rBEem2T6E-rHCVPA" > > F->V->l->1 ? > > So my suspicion is that the hotkey is not lost but points to the random > different command due to wrong ids. > > xmi:id="_tBD5ZFrBEem2T6E-rHCVPA" > xmi:id="_tBD5ZVrBEem2T6E-rHCVPA" > xmi:id="_tBD5ZlrBEem2T6E-rHCVPA" > xmi:id="_tBD5Z1rBEem2T6E-rHCVPA" > xmi:id="_tBD5aFrBEem2T6E-rHCVPA" > xmi:id="_tBD5aVrBEem2T6E-rHCVPA" > xmi:id="_tBD5alrBEem2T6E-rHCVPA" > xmi:id="_tBD5a1rBEem2T6E-rHCVPA" > xmi:id="_tBD5bFrBEem2T6E-rHCVPA" > > I have 942 commands defined in the workbench.xml. But if I spotted the rule > correctly (6th letter a-zA-z and four different letters next) we can have > commands only for 8 English alphabets :) > I also noticed that xml:id are re-generated during restart. That might > explain why the problem suddenly appears. > > Used Eclipse for RCP and RAP Version: 2018-12 with IntelliJ IDEA keymap > plugin. @Ed: any idea if this something coming from EMF?
Certainly UUID generation cannot return non-unique IDs: https://git.eclipse.org/c/emf/org.eclipse.emf.git/tree/plugins/org.eclipse.emf.gwt.ecore/src/org/eclipse/emf/ecore/util/EcoreUtil.java#n3842 It implements this specification: https://tools.ietf.org/id/draft-mealling-uuid-urn-02.txt It's an unfortunate fact that while being universally unique, to the human eye, it's just an eye chart test to see how one UUID actually looks different from another. Also, the method to set an ID cannot result in duplicates: https://git.eclipse.org/c/emf/org.eclipse.emf.git/tree/plugins/org.eclipse.emf.ecore.xmi/src/org/eclipse/emf/ecore/xmi/impl/XMLResourceImpl.java#n611 Though the maps themselves are visible and could be directly manipulated to create such an inconsistency. I'm not sure if the workbench model infrastructure does any direct manipulation of the IDs being used when saving its resources. Mostly UUID assignment would be handled automatically by this code, which could generate a new UUID or reuse the ID if the object was removed from a resource in which it was assigned a UUID: https://git.eclipse.org/c/emf/org.eclipse.emf.git/tree/plugins/org.eclipse.emf.ecore.xmi/src/org/eclipse/emf/ecore/xmi/impl/XMLResourceImpl.java#n671
Created attachment 280891 [details] Paste UI Freeze log Just lost Ctrl-V functionality (or past as a whole), I was quickly pasting some text in a Java editor. I noticed some flickering in the UI, after that past stopped working. I did notice that the UI had a freeze when pushing Ctrl-V after functionality broke. Freeze trace is attached.
Anyone works on that issue? It's super annoying... if I could I would change the text Editor immediately but I work in SAP, so there is no really any other option...
