Also filter out keypresses when focused on contenteditable elements

[crittermike]

I just overrode key.filter() to also ignore keypresses when the current element is contenteditable, using this code:

key.filter = function(event) {
  var tagName = (event.target || event.srcElement).tagName;
  var editable = (event.target || event.srcElement).getAttribute('contenteditable');
  return !(tagName == 'INPUT' || tagName == 'SELECT' || tagName == 'TEXTAREA' || editable);
}

I'm not sure if that's the best way to implement it, but it seems like this would be a good default, no?

[davidchambers]

The element's isContentEditable property is possibly a better source of information, though I don't know how widely supported it is.

key.filter = function(event) {
  var el = event.target || event.srcElement;
  return !(el.isContentEditable || el.tagName == 'INPUT' ||
           el.tagName == 'SELECT' || el.tagName == 'TEXTAREA');
}

[focusaurus]

+1

[davidchambers]

Would you accept a pull request for this change, @madrobby?

[ajb]

👍 is there any reason this has been open for a year and half? I'm happy to PR if that's all it needs.

[madrobby]

@ajb not everyone needs this, that's why the filter function is easily overridable. I'd merge a PR with extensive tests tho. It needs detection of the browser supports isContentEditable, I have no idea about how widespread support is. Remember that kemaster should work on older browsers.

[ajb]

Thanks -- to your credit, key.filter is very-well documented 😀. I'll see if I can whip something together...

[manoharank]

@madrobby Awesome library so far. 👍 to add contenteditable elements in the default filter.