This Bugzilla instance is a read-only archive of historic NetBeans bug reports. To report a bug in NetBeans please follow the project's instructions for reporting issues.
061101 but for some time before now; JDK 6 b102. Often, but not usually, when I invoke an action using the KB, by using menu and menu item mnemonics, the last character I press (mnemonic for the menu item) is inserted into the editor after the action is invoked. For example, I press Alt-F T to open properties for the current project, and a 't' is inserted at caret in the editor. I seem to recall this used to happen a lot and something was supposedly fixed in KB event handling. But if so, the problem is back. Did anything change recently in this area? I am suspicious of revision 1.21 of ShortcutAndMenuKeyEventProcessor.java. Actually I'm suspicious of the very existence of this class. It can be dangerous, especially if the action involves saving the current file (or all files) when it runs, as the bogus character is thus inserted into your source file, possibly without you being aware of it. IIRC sometimes the extra character is inserted into some other GUI element, e.g. the quick search field of the Projects tab explorer, or the message textarea of the CVS Commit dialog. For this reason I believe the bug is in core rather than e.g. the editor implementation; keypresses are not getting consumed reliably, perhaps.
> It can be dangerous, especially if the action involves saving the current file > (or all files) when it runs, as the bogus character is thus inserted into your > source file, possibly without you being aware of it. Sometime happens to me when "Alt-f n". Making underlying file uncompilable. Also once happened to me during "Alt-c d" doing diff and then commiting without mentioning inserted 'd': http://apisupport.netbeans.org/source/browse/apisupport/project/src/org/netbeans/modules/apisupport/project/CreatedModifiedFilesFactory.java?r1=1.29&r2=1.30 Maybe the similar happened to Jesse as well? http://openide.netbeans.org/source/browse/openide/awt/src/org/openide/awt/StatusLineElementProvider.java?r1=1.3&r2=1.4 In my case there were almost broken build. I thought I filed a bug again CVS but can't find it know. Will put a note here if I find it.
Continues to happen to me regularly; significantly interferes with routine IDE usage. Any ideas?
No, I admit I don't know how to fix this. It also never hapenned to me...
Possibly platform-specific. Currently I am running JDK 7 on Fedora Core 6. Happens to me quite often, so if there is some way of enabling logging that coulc diagnose this, I would turn it on.
Just happened to me on projects/queries/nbproject/project.xml.
Anyway way to get logging on this so we can track down why it is happening?
I will try to look at it.
Does it happen to anyone? I tried on Ubuntu 7.04 (GTK L&F if it can make any difference) JDK 6u1, 6u2, 7b14, Gnome, dev build 200707231200. I tried mostly Alt-f t, quickly, slowly, dialog is always displayed, editor untouched.
Just happened to me a few minutes ago! 070725, JDK 7 b16, Ocean L&F, Ubuntu/Gnome/Metacity, Alt-F O. I chose a file to open in the filechooser and noticed that in the previously selected file, the text selection had been replaced with 'o'.
I commented out some workaround for JDK 1.4 in ShortcutAndMenuKeyEventProcessor.dispatchKeyEvent. Please try if it helps or not. If not I will add logging to this class. I suspect it is possible that key event is sent 2 times and because dialog is not yet active in this moment and menu is already discarded second key event is passed to editor. But it is just my speculation. I saw this problem just a few times. So I cannot verify if any change fixes this or not.
Created attachment 47056 [details] Patch
I went ahead and deleted that old workaround: Checking in ShortcutAndMenuKeyEventProcessor.java; /shared/data/ccvs/repository/core/windows/src/org/netbeans/core/windows/ShortcutAndMenuKeyEventProcessor.java,v <-- ShortcutAndMenuKeyEventProcessor.java new revision: 1.23; previous revision: 1.22 done In my tests, both JDK 5 and 6 correctly send the Alt modifier, so I think it is obsolete. I doubt it was the cause of this bug, though. Of course I cannot reproduce on demand so it is hard to know what would fix this.
Happened to me twice today in 070913 on JDK 6u2. Alt-I D to get a diff inserted 'd', Alt-H A to get the About box inserted 'a'. Seems to happen when the IDE is under some load, i.e. a timing issue.
I found only one possible cause: When I accidentally press second letter twice and second press is dispatched to editor before dialog is displayed (ie. dialog is focused and becomes key event target). Eg 'Alt-f' and 't' second 't' goes to editor. This might happen on some 'sensible' keyboard. (It often happenned to me on old MacBook.) It is possible to confirm/reject this hypothesis simply by adding logging to beginning of ShortcutAndMenuKeyEvenProcessor.dispatchKeyEvent. If this is the case you should see 2 't' key event groups in log. I attach example to demonstrate what I mean. Logging code is simply: System.out.println("dispatchKeyEvent ev:" + ev);
Created attachment 48922 [details] Log from double 't' key event
I doubt that is it. I use a laptop with a pretty new keyboard, and I never see accidentally doubled keystrokes under any other conditions. Also this would not explain why the bug seems to happen mostly when the IDE is under load, which to me indicates a race condition of some kind.
In any case please add logging to ShortcutAndMenuKeyEvenProcessor.dispatchKeyEvent and eventually you can use logger to redirect it to IDE log. When problem happens again we can look at events. There is no other way how to investigate this behavior I am aware of.
Me add logging? You add logging, at level FINER (I suppose) and tell me which logger component to enable - I will run with it on. I do not want to run with patched sources indefinitely, and there might be other people (Martin?) who should run with it on.
Yup, I can apply a patch, if available. I did not reproduce for longer time, however.
Ok. I added logging. Use -J-Dorg.netbeans.core.windows.ShortcutAndMenuKeyEventProcessor.level=0. /cvs/core/windows/src/org/netbeans/core/windows/ShortcutAndMenuKeyEventProcessor.java new revision: 1.24; previous revision: 1.23
I will do so.
I guess the waiver for 6.0 is approved. Marking so. Anyway, if we have some logging output which helps us find the root cause, we could still go and fix.
I've been running with logging on for a while now but I have not seen it happen.
Today Alt-F T left a 't' in my document. FINE [org.netbeans.core.windows.ShortcutAndMenuKeyEventProcessor]: dispatchKeyEvent ev: KEY_PRESSED,keyCode=18,keyText=Alt,keyChar=Undefined keyChar,modifiers=Alt,extModifiers=Alt,keyLocation=KEY_LOCATION_LEFT source:org.openide.text.QuietEditorPane FINE [org.netbeans.core.windows.ShortcutAndMenuKeyEventProcessor]: dispatchKeyEvent ev: KEY_PRESSED,keyCode=70,keyText=F,keyChar='f',modifiers=Alt,extModifiers=Alt,keyLocation=KEY_LOCATION_STANDARD source:org.openide.text.QuietEditorPane FINE [org.netbeans.core.windows.ShortcutAndMenuKeyEventProcessor]: dispatchKeyEvent ev: KEY_TYPED,keyCode=0,keyText=Unknown keyCode: 0x0,keyChar='f',modifiers=Alt,extModifiers=Alt,keyLocation=KEY_LOCATION_UNKNOWN source:org.openide.text.QuietEditorPane FINE [org.netbeans.core.windows.ShortcutAndMenuKeyEventProcessor]: dispatchKeyEvent ev: KEY_RELEASED,keyCode=18,keyText=Alt,keyChar=Undefined keyChar,keyLocation=KEY_LOCATION_LEFT source:javax.swing.JRootPane FINE [org.netbeans.core.windows.ShortcutAndMenuKeyEventProcessor]: dispatchKeyEvent ev: KEY_RELEASED,keyCode=70,keyText=F,keyChar='f',keyLocation=KEY_LOCATION_STANDARD source:javax.swing.JRootPane FINE [org.netbeans.core.windows.ShortcutAndMenuKeyEventProcessor]: dispatchKeyEvent ev: KEY_PRESSED,keyCode=84,keyText=T,keyChar='t',keyLocation=KEY_LOCATION_STANDARD source:javax.swing.JRootPane FINE [org.netbeans.core.windows.ShortcutAndMenuKeyEventProcessor]: dispatchKeyEvent ev: KEY_TYPED,keyCode=0,keyText=Unknown keyCode: 0x0,keyChar='t',keyLocation=KEY_LOCATION_UNKNOWN source:javax.swing.JRootPane FINE [org.netbeans.core.windows.ShortcutAndMenuKeyEventProcessor]: dispatchKeyEvent ev: KEY_RELEASED,keyCode=84,keyText=T,keyChar='t',keyLocation=KEY_LOCATION_STANDARD source:org.openide.text.QuietEditorPane
I have the same log but no char in editor, do you see any difference? I have no idea why KEY_RELEASED has source QuietEditorPane but it does not cause this problem in my case. What your log in case it works correctly? My usual correct log: FINE [org.netbeans.core.windows.ShortcutAndMenuKeyEventProcessor]: dispatchKeyEvent ev: KEY_PRESSED,keyCode=18,keyText=Alt,keyChar=Undefined keyChar,modifiers=Alt,extModifiers=Alt,keyLocation=KEY_LOCATION_LEFT source:org.openide.text.QuietEditorPane FINE [org.netbeans.core.windows.ShortcutAndMenuKeyEventProcessor]: dispatchKeyEvent ev: KEY_PRESSED,keyCode=70,keyText=F,keyChar='f',modifiers=Alt,extModifiers=Alt,keyLocation=KEY_LOCATION_STANDARD source:org.openide.text.QuietEditorPane FINE [org.netbeans.core.windows.ShortcutAndMenuKeyEventProcessor]: dispatchKeyEvent ev: KEY_TYPED,keyCode=0,keyText=Unknown keyCode: 0x0,keyChar='f',modifiers=Alt,extModifiers=Alt,keyLocation=KEY_LOCATION_UNKNOWN source:org.openide.text.QuietEditorPane FINE [org.netbeans.core.windows.ShortcutAndMenuKeyEventProcessor]: dispatchKeyEvent ev: KEY_RELEASED,keyCode=70,keyText=F,keyChar='f',modifiers=Alt,extModifiers=Alt,keyLocation=KEY_LOCATION_STANDARD source:javax.swing.JRootPane FINE [org.netbeans.core.windows.ShortcutAndMenuKeyEventProcessor]: dispatchKeyEvent ev: KEY_RELEASED,keyCode=18,keyText=Alt,keyChar=Undefined keyChar,keyLocation=KEY_LOCATION_LEFT source:javax.swing.JRootPane FINE [org.netbeans.core.windows.ShortcutAndMenuKeyEventProcessor]: dispatchKeyEvent ev: KEY_PRESSED,keyCode=84,keyText=T,keyChar='t',keyLocation=KEY_LOCATION_STANDARD source:javax.swing.JRootPane FINE [org.netbeans.core.windows.ShortcutAndMenuKeyEventProcessor]: dispatchKeyEvent ev: KEY_TYPED,keyCode=0,keyText=Unknown keyCode: 0x0,keyChar='t',keyLocation=KEY_LOCATION_UNKNOWN source:javax.swing.JRootPane FINE [org.netbeans.core.windows.ShortcutAndMenuKeyEventProcessor]: dispatchKeyEvent ev: KEY_RELEASED,keyCode=84,keyText=T,keyChar='t',keyLocation=KEY_LOCATION_STANDARD source:org.openide.text.QuietEditorPane
When it works correctly I have the same log, it seems.
Here is from Alt-I D inserting 'd': FINE [org.netbeans.core.windows.ShortcutAndMenuKeyEventProcessor]: dispatchKeyEvent ev: KEY_PRESSED,keyCode=18,keyText=Alt,keyChar=Undefined keyChar,modifiers=Alt,extModifiers=Alt,keyLocation=KEY_LOCATION_LEFT source:org.openide.text.QuietEditorPane FINE [org.netbeans.core.windows.ShortcutAndMenuKeyEventProcessor]: dispatchKeyEvent ev: KEY_PRESSED,keyCode=73,keyText=I,keyChar='i',modifiers=Alt,extModifiers=Alt,keyLocation=KEY_LOCATION_STANDARD source:org.openide.text.QuietEditorPane FINE [org.netbeans.core.windows.ShortcutAndMenuKeyEventProcessor]: dispatchKeyEvent ev: KEY_TYPED,keyCode=0,keyText=Unknown keyCode: 0x0,keyChar='i',modifiers=Alt,extModifiers=Alt,keyLocation=KEY_LOCATION_UNKNOWN source:org.openide.text.QuietEditorPane FINE [org.netbeans.core.windows.ShortcutAndMenuKeyEventProcessor]: dispatchKeyEvent ev: KEY_RELEASED,keyCode=73,keyText=I,keyChar='i',modifiers=Alt,extModifiers=Alt,keyLocation=KEY_LOCATION_STANDARD source:javax.swing.JRootPane FINE [org.netbeans.core.windows.ShortcutAndMenuKeyEventProcessor]: dispatchKeyEvent ev: KEY_RELEASED,keyCode=18,keyText=Alt,keyChar=Undefined keyChar,keyLocation=KEY_LOCATION_LEFT source:javax.swing.JRootPane FINE [org.netbeans.core.windows.ShortcutAndMenuKeyEventProcessor]: dispatchKeyEvent ev: KEY_PRESSED,keyCode=68,keyText=D,keyChar='d',keyLocation=KEY_LOCATION_STANDARD source:javax.swing.JRootPane FINE [org.netbeans.core.windows.ShortcutAndMenuKeyEventProcessor]: dispatchKeyEvent ev: KEY_TYPED,keyCode=0,keyText=Unknown keyCode: 0x0,keyChar='d',keyLocation=KEY_LOCATION_UNKNOWN source:org.openide.text.QuietEditorPane FINE [org.netbeans.core.windows.ShortcutAndMenuKeyEventProcessor]: dispatchKeyEvent ev: KEY_RELEASED,keyCode=68,keyText=D,keyChar='d',keyLocation=KEY_LOCATION_STANDARD source:org.openide.text.QuietEditorPane This seems different: the TYPED event is in the QEP, not JRP.
Here is Alt-I O leaving 'o' at beginning of commit message: FINE [org.netbeans.core.windows.ShortcutAndMenuKeyEventProcessor]: dispatchKeyEvent ev: KEY_PRESSED,keyCode=18,keyText=Alt,keyChar=Undefined keyChar,modifiers=Alt,extModifiers=Alt,keyLocation=KEY_LOCATION_LEFT source:org.openide.explorer.view.TreeView$ExplorerTree FINE [org.netbeans.core.windows.ShortcutAndMenuKeyEventProcessor]: dispatchKeyEvent ev: KEY_PRESSED,keyCode=73,keyText=I,keyChar='i',modifiers=Alt,extModifiers=Alt,keyLocation=KEY_LOCATION_STANDARD source:org.openide.explorer.view.TreeView$ExplorerTree FINE [org.netbeans.core.windows.ShortcutAndMenuKeyEventProcessor]: dispatchKeyEvent ev: KEY_TYPED,keyCode=0,keyText=Unknown keyCode: 0x0,keyChar='i',modifiers=Alt,extModifiers=Alt,keyLocation=KEY_LOCATION_UNKNOWN source:org.openide.explorer.view.TreeView$ExplorerTree FINE [org.netbeans.core.windows.ShortcutAndMenuKeyEventProcessor]: dispatchKeyEvent ev: KEY_RELEASED,keyCode=73,keyText=I,keyChar='i',modifiers=Alt,extModifiers=Alt,keyLocation=KEY_LOCATION_STANDARD source:javax.swing.JRootPane FINE [org.netbeans.core.windows.ShortcutAndMenuKeyEventProcessor]: dispatchKeyEvent ev: KEY_RELEASED,keyCode=18,keyText=Alt,keyChar=Undefined keyChar,keyLocation=KEY_LOCATION_LEFT source:javax.swing.JRootPane FINE [org.netbeans.core.windows.ShortcutAndMenuKeyEventProcessor]: dispatchKeyEvent ev: KEY_PRESSED,keyCode=79,keyText=O,keyChar='o',keyLocation=KEY_LOCATION_STANDARD source:javax.swing.JRootPane FINE [org.netbeans.core.windows.ShortcutAndMenuKeyEventProcessor]: dispatchKeyEvent ev: KEY_TYPED,keyCode=0,keyText=Unknown keyCode: 0x0,keyChar='o',keyLocation=KEY_LOCATION_UNKNOWN source:org.netbeans.modules.versioning.system.cvss.ui.components.KTextArea FINE [org.netbeans.core.windows.ShortcutAndMenuKeyEventProcessor]: dispatchKeyEvent ev: KEY_RELEASED,keyCode=79,keyText=O,keyChar='o',keyLocation=KEY_LOCATION_STANDARD source:org.netbeans.modules.versioning.system.cvss.ui.components.KTextArea
Filed http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6622060
I think without some way to reproduce in a demo application the JDK bug will be ignored or closed. For what it's worth, this bug has been happening to me quite a lot recently. Possibly due to upgrading to Ubuntu 7.10 but that is just speculation. (I have narrowly avoided committing uncompilable code on a couple of occasions after using Alt-I D to examine diffs before commit.) So if you have some other ideas about what to log, I can probably get it to happen with diagnostics on. Please note that I use Ocean L&F, not GTK.
Just observed in Ocean L&F on JDK 5 on a fresh user dir: Alt-F T got properties of a project but left 't' in the editor.
Yesterday I committed a typo in the cvs. See issue #121266. I used the shortcut ALT-I w many times and Jesse mentioned this issue. I can not say that this issue caused the typo for 100%, but there is big probability.
Accepted as JDK issue http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6493715. Closing as WONTFIX.