added: preventDefault to allow overriding browser key bindings #2

Closed
shrunyan wants to merge 1 commit from prevent-default into master
shrunyan commented 2019-01-25 21:36:10 +01:00 (Migrated from github.com)

We are building a link creation/editing experience. Most editing experiences use the command Mod-k to create/edit links. e.g. Gmail, Gdocs, Medium, etc... But some OS/browsers (e.g. Ubuntu/Firefox) default Mod-k to highlighting the browser url input. Therefore it's necessary to prevent the default behavior so once our link editing modal opens we can focus on the modal input for the ProseMirror editor link url.

Focusing within a modal is a concrete example I currently have but imagine user intent when providing a key binding would be to override any default browser behavior.

We are building a link creation/editing experience. Most editing experiences use the command `Mod-k` to create/edit links. e.g. Gmail, Gdocs, Medium, etc... But some OS/browsers (_e.g. Ubuntu/Firefox_) default `Mod-k` to highlighting the browser url input. Therefore it's necessary to prevent the default behavior so once our link editing modal opens we can focus on the modal input for the ProseMirror editor link url. _Focusing within a modal is a concrete example I currently have but imagine user intent when providing a key binding would be to override any default browser behavior._
shrunyan commented 2019-01-25 21:38:49 +01:00 (Migrated from github.com)

Giving this a second thought. It might be better if the event was provided to the key binding callback as a fourth argument and leave it up to the implementer to determine if they want to cancel the event. Any thoughts on that?

Giving this a second thought. It might be better if the event was provided to the key binding callback as a fourth argument and leave it up to the implementer to determine if they want to cancel the event. Any thoughts on that?
marijnh commented 2019-01-25 22:56:10 +01:00 (Migrated from github.com)

Returning true from the handler (which it does for handled keys) will cause the editor to call preventDefault. Calling preventDefault for all keys, as your patch is doing, doesn't seem like a good idea at all.

Returning true from the handler (which it does for handled keys) will cause the editor to call `preventDefault`. Calling `preventDefault` for _all_ keys, as your patch is doing, doesn't seem like a good idea at all.
shrunyan commented 2019-01-30 04:43:56 +01:00 (Migrated from github.com)

Thanks! Didn't catch that in the docs. Found it here, https://prosemirror.net/docs/guide/#commands

Would love to setup a pull request in ProseMirror/website for the reference section but I'm having a difficult time understanding how that content gets added in the build step.

Thanks! Didn't catch that in the docs. Found it here, https://prosemirror.net/docs/guide/#commands Would love to setup a pull request in [ProseMirror/website](http://github.com/ProseMirror/website) for the [reference section](https://prosemirror.net/docs/ref/#keymap) but I'm having a difficult time understanding how that content gets added in the build step.

Pull request closed

Sign in to join this conversation.
No reviewers
No labels
No milestone
No project
No assignees
1 participant
Notifications
Due date
The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference
prosemirror/prosemirror-keymap!2
No description provided.