handleKeyCommand doesn't honor "not-handled"
See original GitHub issueDo you want to request a feature or report a bug?
bug
What is the current behavior?
Currently if you provide a handleKeyCommand
function, it doesn’t fall through to the default key binding if you return not-handled
. I would expect that if you returned not-handled
from that function that it would allow the underlying key press to go through.
From the docs:
The ‘myeditor-save’ command can be used for our custom behavior, and returning ‘handled’ instructs the editor that the command has been handled and no more work is required.
By returning ‘not-handled’ in all other cases, default commands are able to fall through to default handler behavior.
If the current behavior is a bug, please provide the steps to reproduce and if possible a minimal demo of the problem.
Here is an example: https://codepen.io/michael_cox/pen/xrvdRW
The important part is this:
function myKeyBindingFn(e) {
if (e.keyCode === 65 /* a key */) {
return 'editor-a';
} else if (e.keyCode === 66 /* b key */) {
return 'editor-b';
}
return getDefaultKeyBinding(e);
}
handleKeyCommand(cmd) {
if (cmd === 'editor-a') {
return 'not-handled'; // Should fall through to default key functionality?
} else if (cmd === 'editor-b') {
return 'handled';
}
return 'not-handled';
}
What is the expected behavior?
I would expect that in this case if you type the letter a
, which returns not-handled
, that it would let the underlying keypress to go through and the letter a
would be typed to the editor. If you type the letter b
, which returns handled
, it should not go through and the editor would assume that keypress has been handled some other way. Currently the keypress is stopped in both cases.
I think this may be caused because of this: https://github.com/facebook/draft-js/blob/master/src/component/handlers/edit/editOnKeyDown.js#L150
It says at this point it’s safe to stop the keypress, but I think that’s probably only true if the next if
statement passes where it checks to see if there was a handled event of some kind.
Which versions of Draft.js, and which browser / OS are affected by this issue? Did this work in previous versions of Draft.js?
Chrome 59, 0.10.1 of Draft.
Issue Analytics
- State:
- Created 6 years ago
- Reactions:3
- Comments:7 (2 by maintainers)
Top GitHub Comments
One last suggestion then, for posterity if nothing else. It would seem that the
<Editor />
doesn’t need to support both props. SincekeyBindingFn
is called on every key press, and returninggetDefaultKeyBinding(e)
works as I’d expect it to,handleKeyCommand
doesn’t seem to provide anything additional. If you wanted to call a separate function like that you could do so manually without relying on the framework.But I still stick by my original post that the way things are currently implemented feels incorrect.
use
return undefined
, instead ofreturn "not-handled"
https://github.com/draft-js-plugins/draft-js-plugins/issues/1117