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.
| Summary: | Existing shortcuts show/hide inconsistently in top-level menus | ||
|---|---|---|---|
| Product: | editor | Reporter: | Petr Somol <psomol> |
| Component: | Actions/Menu/Toolbar | Assignee: | Milutin Kristofic <mkristofic> |
| Status: | RESOLVED WONTFIX | ||
| Severity: | normal | CC: | jhavlin, ovrabec |
| Priority: | P3 | Keywords: | UI |
| Version: | 7.3 | ||
| Hardware: | PC | ||
| OS: | Windows 7 | ||
| Issue Type: | DEFECT | Exception Reporter: | |
| Bug Depends on: | 203741 | ||
| Bug Blocks: | |||
| Attachments: | screenshots of the same menu with and without some of the shortcuts | ||
Able to reproduce: 1) Open a file in editor 2) Open another top component (not file editor), e.g. Task Editor for this task 3) Switch to the task editor and click inside a text area 4) Open Edit menu twice. E.g. Select All action is missing its shortcut 5) Now switch to the file editor 6) Open Edit menu => Select All still has no shortcut 7) Close and reopen the Edit menu, now the shortcut should be back. The primary problem is that org.netbeans.modules.editor.MainMenuAction.addAccelerators switches the action's accelerator on and off too many times when switching top components. Debugging on JMenuItem.setAccelerator reveals that when switched to file's editor, it's called several times with "Ctrl-A", "null", "Ctrl-A", "null". Then when menu is opened and painted editor finally sets accelerator to "Ctrl-A" which is unfortunately too late because the item is already painted. JMenuItem.setAccelerator calls repaint and revalidate but for some reason the menu is not repainted when it has focus. I have to click into another application and then back to get it repainted. If editor is doing its best (i am not sure because obviously it cannot decide on whether to set the accelerator on/off and changes the value several times) then maybe openide.awt.MenuBar.LazyMenu (class for Edit menu instance) could maybe listen on propertyChangeEvent fired by JMenuItem and then repaint the hwole menu??? Passing first to editor to evaluate why it sets accelerators in such a weird way. This old bug may not be relevant anymore. If you can still reproduce it in 8.2 development builds please reopen this issue. Thanks for your cooperation, NetBeans IDE 8.2 Release Boss |
Created attachment 131900 [details] screenshots of the same menu with and without some of the shortcuts While investigating menu contents for future structure redesign we discovered that there is a wide-ranging problem with the display of shortcuts. Not all existing shortcuts are displayed with the respective menu items; the more strange fact is that they get displayed sometimes, under circumstances I could not identify exactly, nor reproduce. I am attaching a screenshot of Edit menu contents, the left one is seen more commonly throughout one IDE session, the right one shows up for a short while from time to time (can not tell for sure, but have seen it after I changed focus out of NB and later returned back). This problem is not Edit menu specific, it can be observed also in at least Navigate, Source and Refactor menus. Sorry if I assign this report to wrong category, was not sure where menus belong to.