Community
Participate
Working Groups
Created attachment 222020 [details] The app with the bug. If you have a view with a treeviewer/tableviewer and a text widget, than a command that is binded to the DEL key disables the DEL key in the text widget. In my example a DeleteCommand is bind to DEL and there is a view with a huge text widget. If you type text there and select it you can not delete it anymore by pressing DEL.
This bug is similar to bug 348559, but not the same. When workbench key-binding mechanism (extension point) is used, all bindings is added both to the display ACTIVE_KEYS and CANCEL_KEYS lists (see org.eclipse.jface.bindings.BindingManager.updateKeyBindingList()). In RCP the DEL and ESC keys are so called out-of-order keys (see org.eclipse.ui.internal.keys.WorkbenchKeyboard.outOfOrderKeys), which are treated differently. Unfortunately, out-of-order keys are not supported in RAP. The solution will be to follow bug 54654 comment#4 - "Text widgets no longer accept "DEL" as a key binding; they will only direct "DEL" to the widget itself."
*** Bug 394071 has been marked as a duplicate of this bug. ***
We could remove the DEL key from CANCEL_KEYS lists in org.eclipse.jface.bindings.BindingManager.updateKeyBindingList() and enable WorkbenchKeyboard# isOutOfOrderKey() code for DEL. With this approach the default behavior on the client for DEL will not be suppressed and DEL key binding will not be triggered if DEL is pressed on Text and Combo (see WorkbenchKeyboard#filterKeySequenceBindings).
Not only the DEL key is affected. Also Ctrl+V and other key bindings used by commands.
(In reply to Markus Krüger from comment #4) > Not only the DEL key is affected. Also Ctrl+V and other key bindings used by > commands. Yes, that is to be expected. However, as far as I can tell the same would happen in RCP, since those keys don't get any kind of special treatment. I have been wondering why DEL is the only exception, but I guess bindings on backspace or arrow keys (without modifier) are more unusual.
Nope, our application is single sourced and the RCP version is working.
I think the most feasable solution would be to no longer allow text-editing keys/shortcuts to be canceled white text-fields are focused. I'm not 100% sure yet how to implement it, and it's not entirely trivial since there are different combinations on different OS. Overall it shouldn't be more than two days or so. However, since this is a change in existing behavior it won't be part of the 2.3 release, just 3.0.
