Allow for disabling hotkey commands

[BrianGenisio]

I need the ability to un-register hotkey presses. Specifically, we want tabs to not indent, but focus on the next element... we want the editor to behave more like a native component.

With this PR, I can un-register hotkey presses by registering nothing:

$editor.wysiwyg({
    hotKeys: {
        'tab': ''
    }
});

[codewithtyler]

While this does work with the tab, when I tried testing this against other hotkeys such as bold it didn't work. Here's what I used:

$("#editor").wysiwyg({
    hotKeys: {
        "Ctrl+b meta+b": ""
    }
});

I also tried

$("#editor").wysiwyg({
    hotKeys: {
        "Ctrl+b meta+b": "",
         "Ctrl+z": ""
    }
});

with no luck. I'm not exactly sure why it fixes the issue with tabs but not with keyboard shortcuts.

[BrianGenisio]

I believe that is because for ctrl-b and ctrl-z, the default command inside of a content-editable section is "bold" and "undo".

That isn't the case for tab or many other hot keys (ctrl-r, ctrl-l, ctrl-u, etc)

See here: http://codepen.io/BrianGenisio/pen/pyzxwy

[codewithtyler]

Oddly enough, when I use this

$("#editor").wysiwyg({
     hotKeys: {
          "Ctrl+u": "",
          "Ctrl+l meta+l": "",
          "Ctrl+r meta+r": ""
     }
});

and I hit Ctrl + u the highlighted text still gets underlined. Ctrl + l and Ctrl + r gets disabled like it should.

[steveathon]

I know between windows and OSX there is a different set of behavior, the source of some previous issues with the hotkeys. We should test the full set and check which ones cause problems, if there's not already a note elsewhere.

[steveathon]

Did we get to the bottom of why the defaults for B + U are not being stopped? If so, we can probably merge this.

[codewithtyler]

I have not yet found anything online to support this but from what I understand of @BrianGenisio's comment earlier. In a content-editable div each browser has automatic support of the bold and underline hotkeys.

After doing some testing last night; however, this certainly does seem to be the case.

[BrianGenisio]

Correct. The Command System in the DOM is all about editor functions. And when contentEditable=true the browser includes a lot of default commands.

https://developer.mozilla.org/en-US/docs/Web/API/Document/execCommand#Commands

These may change based on browser implementation, which is why I'm assuming that the hotkeys are mapped to something explicit.

This change really just gives me a way to not register anything, and let the browser do it for me. We support changing what the hotkeys mean, we just don't support doing nothing, and this PR will do that.

It would also be nice to be able to assign a function to the hotkey override, instead of execute a command. That would be even more flexible, but more change. With this change, I can un-register the built-in command, and then register my own hotkey separately, and I still get the flexibility I need.

[codewithtyler]

I'd also like to note that this PR fixes #59.

[codewithtyler]

@BrianGenisio If you will create an issue with detailed information about your idea of having a hotkey override I'll see about looking into finding some time this month to work on it.

[codewithtyler]

@steveathon this is good to go. You can merge it. You can also close issue #59 assuming that merging this PR doesn't automatically close it.

[codewithtyler]

Thanks @BrianGenisio for your contribution.