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 build 200709040000 1) Open "Search Results" in the bottom (fire some sort of find operation) 2) Give the "Projects" tab focus in the top-left 3) Hit ALT-E (I expect the Edit pulldown menu to come down) 4) Modify Crit[e]ria (in the Search Results tab) gets fired instead even though it doesn't have window focus I think this violates the rule of "least surprise". Windows that are in the background should disable their Mnemonics.
Reassigning to "utilities" for evaluation.
This is an interesting issue. If I fix it (by removing the mnemonic from "Modify Criteria"), I will cause a bug that the Modify Criteria button does not have any mnemonic. The only safe solution seems to be to remove all text-labelled buttons from the Search Results window. I will ask our UI specialists about the best solution.
I would recommend against this approach. Can't you retain the Mnemonics but ensure they only fire if the tab has focus? Worse case scenario you could emulate this by removing the Mnemonics every time the tab loses focus and re-bind them when it regains focus.
I forgot about the important thing that the mnemonic works even if the Search Results view is not focused, I am sorry. I was curious whether the Search Results window is the only one with this problem. So I tried other types of windows available in the small ("basic") NetBeans installation. I found that most windows do not contain any text-labelled buttons and among those who do, most of these buttons do not have any mnemonic assigned. I actually found just one other window where I could check this issue - it's the Refactoring preview window. It has two buttons with mnemonics: "Do (R)efactoring" and "(C)ancel". Both these mnemonics work even if the Projects view is activated, i.e. it suffers from the same problem as the Search Results window. To make the Refactoring preview displayed with these buttons enabled, I did the following: 1) Open some Java source file with a class with at least one field declared. 2) From the editor's context menu or from the main menu, select Refactor > Encapsulate Fields... 3) In the Encapsulate Fields dialogue, in the table, check at least one check-box and press the Preview button. Refactoring window is then displayed, with the two buttons "Do Refactoring" and "Cancel". I consider this to be a bug in the window system - it should ensure that only mnemonics from within active windows are activated. Reassigned to "core/window system" for further evaluation.
the same for the svn and cvs versioning view
This is correct/standard Swing behavior. Mnemonic is global and works regardless of focus. If there is conflict between mnemonic in menu and button button takes precedence ie. button will eat key event and menu will not know about it. In addition there is no way how window system could handle this. Possible solutions: 1.Do not use mnemonic inside TopComponents. 2.If you use mnemonic be sure it does not conflict with another mnemonic. (You cannot expect that it will work if you have 2 menus with the same mnemonic so why do you expect it will work with the same mnemonic for menu and button?) 3.If you really want to use the same mnemonic (which is *WRONG* and bug on UI/HIE side) be sure you will not consume mnemonic when your TC is not active. IMO it is bug is UI specification - mnemonic conflict. If this cannot be fixed it must be workarounded in TC. But mnemonic by design SHOULD work even for non active components. For illustration I attach simple Swing app with one menu item and 2 buttons. Menu item and one button have the same mnemonic. Even if B button is focused user can use mnemonic A and this will select/activate button A not menu A ie. button A takes precedence over menu A when mnemonic A is used. It effectively disables mnemonic on menu A which is wrong.
Created attachment 48927 [details] Test app
I disagree with mslama. From the end-user point of view there are multiple internal frames (i.e. JInternalFrame) within the parent frame and a mnemonic in one frame should not interfere with mnemonics in another window. I believe your objection is based on the fact that underneath the hood you guys implemented this using a single JFrame so mnemonics conflict but I am arguing that from a UI point of view the user doesn't know or care about these implementation details.
gtzabari: ??? Show me one single existing application in the world that uses "focus sensitive" mnemonics. I searched and didn't find any. Instead, I found global mnemonics, like in Firefox History sidebar (View -> Sidebar -> History). Moreover Swing guys probably knew why they made mnemonics work globally, as it seems to correspond with native apps...
Dafe, I do not share you opinion. If you create a Swing application with several internal frames and some UI components inside these frames, only mnemonics for components inside the currently active internal frame will be functional - exactly as gtzabari expects it. I do not see any significant difference between pure Swing JInternalFrames and our TopComponents (as regards expected way of handling mnemonics) so I would expect the same behaviour in NetBeans. I did not find any other application with multiple internal frames (or windows, TopComponents, or whatever - no matter how they are called) so I could not compare. I do not consider this issue fully resolved. I do not have any strong opinion about its severity/priority, though.
JInternalFrames and our TopComponents are totally different system IMO. Shame that you didn't check firefox example I gave. Anyway, it's clear that we can't agree here, so let's leave the decision on usability guys.
I did check but I do no see any apparent parallel between NetBeans and a sidebar in Firefox (there is at most one sidebar in Firefox, while NetBeans has multiple TopComponents). Anyway, I agree to let it up to the usability guys - did you ask them online or offline?
Yes HIE is already informed (Josef Pavlicek should handle duplicate mnemonics). Note: I do not understand your mind flow with JInternalFrames. Does it means that if you have JInternalFrame in app main menu mnemonic should stop to work? So you do not want to use main menu while you work inside JInternalFrame?
Another note: Even if mnemonic conflict will be resolved still mnemonic will work even for non focused components. It is simply how mnemonic generally works. You need not first activate main menu to invoke mnemonic on it. Is it clear? If you want to solve this (ie. you do not want to handle component mnemonic for non active TC) you must handle it in your TC. I do not see any way how window system could solve/handle TC impl.
Ad JInternalFrames: Image a simple application with three menus in the menu bar: Menu A Menu B Menu C where letters A, B and C serve as mnemonics. Below the menu bar, there is a desktop with three internal frames and each internal frame contains one button. Again, letters A, B and C in the buttons' labels serve as mnemonics: +== Frame title ===+ +== Frame title ===+ +== Frame title ===+ | +----------+ | | +----------+ | | +----------+ | | | Button A | | | | Button B | | | | Button C | | | +----------+ | | +----------+ | | +----------+ | +------------------+ +------------------+ +------------------+ If neither of the internal frames is active, invocation of any mnemonic will cause activation of the corresponding menu. If frame with "Button A" is active, invocation of mnemonic "A" (e.g. Alt+A) will activate the button. Invocation of the other mnemonics ("B", "C") will activate the corresponding menus in the menu bar. Similarly for other frames. In short: inactive internal frames behave as if there were no components with mnemonics inside them.
I think I now see the cause of the misunderstanding. Gtzabari said in his original report that "... gets fired even though it does not have window focus". If I understand correctly, he actually wanted to say that the TopComponent containing the Modify Criteria button (i.e. Search Results) was not active. But you interpret is strictly that the button itself was not focused.
1) mpetras is right, I am saying that only focused internal frames should have their components and the associated mnemonics active. I agree that the menu-bar spans across all internal frames but I don't think it is fair to say the same about components which are children of internal frames. 2) I believe that overriding mnemonics used by the menu items is "bad form". Take FireFox for example, since you brought it up: it allows any website to override any mnemonic that is built into the browser. This means that as I browse hundreds of websites a day I never know whether I can use the standard mnemonics safely (even CTRL-N for "New Window" or CTRL-T for "New Tab" are not sacred and may be overriden by a website!). I personally believe that even if the issue discussed in #1 is fixed Netbeans should make it a point to never override mnemonics of the pulldown menus as these span across all internal frames. You definitely shouldn't be overriding mnemonics associated with the root menu items (such as ALT-E for Edit). I don't feel as strongly about the sub-menu items because in my view most of those tend to be context sensitive anyway. 3) Is it possible for us to reopen this issue until HIE gives their opinion?
No I don't think this issue should be reopened. Let me tell me state clearly: I vote for current behavior, I believe it is right and standard. We should just ensure that mnemonics are not in conflict and that's all.
I would suggest to change current menominics ALT +E to the ALT + D as MoDify Criteria. Josef
For your information: The mnemonic for Modify Criteria is updated (see issue #130054). Still I believe the current behavior is unexpected for most users (but I have no hard data). Note: If you want to ensure that there are no conflicts, you must check not only conflicts between a TopComponent and the main menu but also between all TopComponents together.