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.
[dev nov 12, and observed for a few days only, I think starting w/ dev nov 8? Enlightenment, JDK 1.3.1_01] In recent builds, sometimes posting a menu via KB command actually runs the first item instead. For example, I press Alt-T from the Editor and rather than posting the Tools menu, the Go To Class dialog is opened (first in the list). At the same time, Alt-W correctly opens the Window menu and Left moves into the Tools menu normally. This problem does not occur immediately after starting the IDE, it only starts to happen after having used the IDE for a while (and then does not go away until the IDE is restarted). I think I have only observed it with the Tools menu, though I am not sure.
This is a long time JDK issue, not NB. Alt+<letter> actually produces two key events (at least): Alt+<letter> and <letter>. It means pressing Alt+T produces a sequence of Alt+T, which invokes the Tools menu, then T which invokes the menuitem under Tools which has T as mnemonic. I ran into this problem almost three years ago (it was &Help | &Help Contents). I worked around it by removing mnemonic of Help Contents. We may want to invetigate the issue. I suspect that the superfluous <letter> event is KEY_RELEASED <letter> and mnemonic handling reacts to KEY_RELEASED. Just a blind guess.
Strange that I would just start noticing this issue. Specific to 1.3.1_01? Something we changed in focus management? New/changed mnemonics on common actions? Anyway, it is rather annoying, maybe it merits a workaround. E.g. for org.openide.awt to refuse to add a mnemonic to any menu item which is the same as the mnemonic of the menu it is in.
Okay, reopen. We may want to do something with this bug.
I can confirm it happens for other menus too, and always where the item's mnemonic matches the menu's own. Again, it does not occur consistently; in a given IDE session all is well for a while. I have yet to figure out what triggers the bug to start appearing.
just want to stress again this is JDK/OS problem. We'll try to find a workaround but there is no guarantee.
Target milestone -> 3.3.1.
*** Issue 18754 has been marked as a duplicate of this issue. ***
*** Issue 13672 has been marked as a duplicate of this issue. ***
This happens in Windows as well and in Netbean 3.2.1 and 3.3. I submitted the same bug early last week. It seems that you all think it's a jdk bug, but this doesn't seems to happen in Forte using the same JDK. I've also, after further examination, noticed that I can you Alt-E *once* after I start netbeans. then, when I hit C, it does the copy like it should. From that point on, Alt-E refuses to work.
Step to reproduce (at least on my Linux + jdk 1.3.1_01) - start the IDE in SDI mode - open some file in an editor - switch to MDI (Tools->Setup Wizard) - mouse click to the editor (to focus it), press Alt+T, the menuitem "Go &To Class" is invoked immediately. It shouldn't, instead the Tools menu popup should be displayed waiting for the user to select a menuitem Possible workaround: when this starts happening the user can use mouse to pull down any menu from the main menu bar, go around with it using mouse. Then Alt+T will behave as normal Evaluation: I spent a whole lot of time investigating this bug. Strongly suspect that some Swing internal data are corrupted for some reason. Probably an AWT/Swing bug. Any fix would be hacky and it works fine on JDK 1.4. I suggest we won't fix this bug.
*** Issue 19563 has been marked as a duplicate of this issue. ***
I've tried NetBeans 3.2 on JDK1.3.1 on my Linux and everything seems to work OK.
It still happens to me on 1.3.1_02, and it happened to me on 1.4 beta 3, so I disagree that it is fixed in 1.4. I agree it is dangerous to try to fix the problem directly. However we can consider, for example, a special system property hack which would turn on a mode where no menu item would get a mnemonic matching its menu. Basically the Actions.MenuBridge presenter would check for the containing JMenu and disable problematic mnemonics. This would ensure that the bug was not triggered. Does it sound worth the effort? I have become so used to invoking the main menu with Alt-V (View menu is mnemonic-safe) and then continuing to the menu I want with its mnemonic (e.g. Alt-V B B to build), that I can't estimate how much of an impact this bug has on an average user. Mostly confusion, I guess. Note: Alt-E seems to do nothing because ReplaceAction is invoked, but it is disabled.
Reopened. We've tried it on Solaris8, JDK1.4 (two independent machines) and the problem occured every time.
We have tried it on Windows2000 (two machines), on JDK1.3.1 there are not problems, on JDK1.4 is the same behavior as on Solaris (everytime).
Increased to P2. This is a regression, now (3.3rc2) the problem occures every time, not sometimes as was described. From usability and accessibility point of view this bug has very high priority. I've written simple application with a menu. When I run it by external execution, it works OK, when by internal, there is the same problem as in NetBeans menu.
Man, this is not a regression. The only fact that you're now able to reproduce the bug reliably does not mean that we broke something in the code recently. Please don't overuse the word.
KEY_TYPED events are generated even for Alt-T. Such an event should be generated only when the key stroke produces a Unicode character, which it doesn't in our case but KEY_TYPED is generated anyway. Mila knows about this problem for a long time and has a hackaround for it in the editor. He basically ignores any KEY_TYPED which has modifiers != Alt+Ctrl (==RightAlt). This of course doesn't work on MacOS, but probably too much technical details....
Created attachment 4317 [details] patch for release33 (only jdk1.4)
Created attachment 4318 [details] diff against release33
please test the patch on all platforms with jdk 1.4 only, there is no impact when ide runs on jdk 1.3. Things to test besides verifying that the patch really fixed the problem: MDI/SDI, typing national characters in the editor especially with RightAlt, popups of all types including combobox popups dstrupl already reviewed my fix
Created attachment 4320 [details] a better patch for release33
OK, new patch tested. Main problem is gone but one smaller bug still remains. This bug appears only in Explorer - when menu invoked from KB and in Explorer exist node with same first letter then this node is selected except origin selection. This is annoying for user. e.g. CVS menu is invoked but for different node than user wanted(wrong file could be commited to CVS if s/he didn't notice that node selection changed) etc.
Okay, I am going to add a (hopefully) final patch. As I mentioned earlier the root of all evil is the bug in JVM (I believe) which produces an extra KEY_TYPED event even though it shouldn't. This extra event invokes various unexpected actions. The relevant piece of code in NB is different for JDK 1.4 and JDK 1.3 so the symptoms are different but the root cause is the same. The current situation is that I have the hacks for both JDK 1.4 and JDK 1.3. The bug on JDK 1.3 is less severe (not a showstopper) so perhaps we'll decide to integrate only the hack for JDK 1.4 I'll going to attach all I have. What needs to be tested: - MDI/SDI - invoking/navigating popup menus - invoking/navigating pulldown menus (from the main menubar) - combobox popups - shortcuts in general - shortcuts in dialogs (modal and non-modals) Of course if one uses only the patch for JDK 1.3 then only JDK 1.3 should be tested (ditto for the patch for JDK 1.4) [Lukas Hasik wrote] > This bug appears only in Explorer - when menu invoked from KB and in Explorer > exist node with same first letter then this node is selected except origin selection this is not NB-specific. Try the same thing with JDK 1.4/SwingSet2 demo. The patch I am going to attach to this bug report also works around this problem.
Created attachment 4323 [details] final jar patch for release33/jdk 1.3
Created attachment 4324 [details] final jar patch for release33/jdk 1.4
Created attachment 4325 [details] final diff against release33 for jdk 1.3
Created attachment 4326 [details] final diff against release33 for jdk 1.4
weird things happen in Dialog on JDK 1.4. I need to be more conservative with the hack, going to attach a better "final" jar patch for jdk 1.4
Created attachment 4328 [details] a better "final" jar patch for release33/jdk 1.4
Created attachment 4329 [details] a better "final" diff against release33 for jdk 1.4
Created attachment 4339 [details] yet another jar patch for release33/jdk 1.4
I have tried to change menmonic in submenus and it's working with this associations: Edit> Rep&lace Project> P&roject Manager Build> B&uild Debug> D&ebugger Window Versioning> Run &CVS Command Windows> W&indows Tools> Go To Class ...without mnemonics because of many conflicts I didn't use any patch included above.
Attachment id=4339 - a better "final" jar patch for release33/jdk 1.4 tested by me, Lukas and Marian. We consider this patch as the best from all presented. However there is one small issue, that we now do not see as showstopper: When some main menu is opened (e.g. File), pressing mnemonic for another main menu (e.g. alt+t for Tools) invokes associated action in the menu (Go to class dialog). This can be workarounded by invoking the new desired menu after the previous is closed. Main problem seems to be fixed, new small one with suitable workaround exists, so we vote for the latest patch.
"When some main menu is opened (e.g. File), pressing mnemonic for another main menu (e.g. alt+t for Tools) invokes associated action in the menu (Go to class dialog). This can be workarounded by invoking the new desired menu after the previous is closed." - if you have pressed Alt-F to post the File menu, and then press just T (not Alt-T), does the Tools menu correctly post, as works without the patch (and was my workaround for this bug - press Alt-V then the mnemonic of the problematic menu)? Also has anyone besides Trung tested the 1.3 patch yet? I have not gotten a chance to yet.
Small correction: - you can open some popup menu (not only Main menu) and if you press Alt + (Main menu mnemonic) , invoke associated action in the menu : 1. open Source Editor 2. Shift-F10 -> popup menu arise 3. Alt-E -> "Replace" dialog arise
The same result for Combobox popups.
fixed in release33 and trunk, I've already got approvals
QA approves the 2002-01-22 05:40 PST patch for 3.3.1.
Steps to reproduce another minor issue: 1. Open Tools | Options 2. Expand the Editing | Editor Settings node. 3. Select the Indentation Engines node 4. Press Alt-H The help viewer should come up and display the Indentation Properties info. Instead, Alt-H selects the HTML Editor node first and then displays help for the Source Editor Properties.
Marking as verified. The patch works however there are some minor issues that seems to be unfixable - check number of patches where each fixed only part of the problem not whole. To Jesse: Yes after pressing just T works. Also your workaround to pres alt+v and then the mnemonic works.
Putting 3.3.1_CANDIDATE keyword back - reload function doesn't refresh all fileds so when I commited changes to this issue the keyword was wrongly removed.
the JTree thing is a bug in JDK, demonstratable with the SwingSet2 demo. Can someone please take time and file a bug against JDK 1.4? Thanks!!
Just observed this again in [dev feb 11] with the Help menu - pressed Alt-H and it opened the master help set rather than just posting the Help menu. Of course this is not reproducible. :-(
Resolved for 3.4.x or earlier, no new info since then -> closing.