Community
Participate
Working Groups
3.1 org.eclipse.ui.internal.KeyBindingService#unregisterAction If an already unregistered action is unregistered, the keybinding service is deactivated but never reactivated. This is because the keybinding service is deactivated when unregistering the action, but if the unregister did not work (ie handlerSubmission == null) the keybinding service is never reactivated. The "if (handlerSubmission != null) {" check should be moved lower. This is what registerAction and setScopes does. Corrected code: if ((parent != null) && (parent.activeService == this)) { active = true; parent.deactivateNestedService(); } // Remove the current submission, if any. HandlerSubmission handlerSubmission = (HandlerSubmission) handlerSubmissionsByCommandId.remove(commandId); /* * Either activate this service again, or remove the submission * myself. */ if (parent != null) { if (active) { parent.activateNestedService(this); } } else { if (handlerSubmission != null) { Workbench.getInstance().getCommandSupport().removeHandlerSubmission (handlerSubmission); handlerSubmission.getHandler().dispose(); } }
Created attachment 27177 [details] KeyBindingService.patch patch w/ fix
I wish all bugs filed were like this. I'll try to make sure that this makes it into 3.2 M3.
Changing to critical because every time you register a new action while a keybinding is active, the keybinding will always be deactivated. The following happens: 1. registerAction (newAction) 2. registerAction always calls unregisterAction(newAction) 3. unregisterAction deactivates current keybinding 4. unregisterAction tries to unregister newAction but since it's new, you end up with handlersubmission == null 5. keybinding is never reactivated because handlersubmission == null The result for the end user is they cannot use shortcut keys until the keybinding is reactivated another way (usually by clicking another part, then clicking back) This could be confusing to the user, who may think they lost function. This bug was discovered in the WTP multipage XML editor, and since the December release of WTP is currently planning on using the 3.1.1 base, we'd really like this bug to be fixed in 3.1.1. Thanks.
"critical" means "crashes, loss of data, severe memory leak" (https://bugs.eclipse.org/bugs/page.cgi?id=fields.html#bug_severity).
Thanks Doug, just wanted to admit the "critical" setting was my fault in giving bad advice to Amy. I should remember not to rely on my memory. "loss of function" is what we were after. thanks again.
Fixed on the R3_1_maintenance stream. It will have to wait until 3.2 M2 is declared before it can be released to HEAD.
Fix released to HEAD.
Amy: Does this work as expected in 3.1.1 RC2 and 3.2 M2?
(as a note, 3.1.1 RC2 is M20050923-1430)
Just tried 3.1.1 RC2 (M20050923-1430) and it did indeed fix my problem. Thanks!
Marking as verified.
