handleKeyCommand doesn't honor "not-handled"

Do 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.

[michaelcox]

One last suggestion then, for posterity if nothing else. It would seem that the <Editor /> doesn’t need to support both props. Since keyBindingFn is called on every key press, and returning getDefaultKeyBinding(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.

[cr7cr8]

use return undefined , instead of return "not-handled" https://github.com/draft-js-plugins/draft-js-plugins/issues/1117