8

I'll start with the question. When a specific browser has a buggy implementation of a feature and your javascript needs to know whether the current browser has that buggy implementation or not so it can use an alternate strategy, how do you figure out if the implementation is buggy without doing browser type sniffing (which is generally considered bad)?

Here's the whole situation.

I was working on some code that wants to use the "input" event for getting notifications of user changes to an <input type="text"> field (works much more live than the "change" event), but when that event isn't supported, it uses a much more complicated scheme involving a bunch of other events.

Since the "input" event is only supported in some browsers, I went in search of a way to do feature detection for the event (rather than browser user agent sniffing) since feature detection is generally a more robust way of doing things. As such, I came across this great article for doing exactly that and this code seems to work:

var isEventSupported = (function(){
    var TAGNAMES = {
      'select':'input','change':'input',
      'submit':'form','reset':'form',
      'error':'img','load':'img','abort':'img'
    }
    function isEventSupported(eventName) {
      var el = document.createElement(TAGNAMES[eventName] || 'div');
      eventName = 'on' + eventName;
      var isSupported = (eventName in el);
      if (!isSupported) {
        el.setAttribute(eventName, 'return;');
        isSupported = typeof el[eventName] == 'function';
      }
      el = null;
      return isSupported;
    }
    return isEventSupported;
  })();

Then, I ran into problems with IE (surprise, surprise). While IE purports to support the "input" event and it passes the feature test above and it works most of the time, IE's support is buggy as hell. It doesn't even trigger the event when the user hits the backspace key (among other missing behaviors). As such, I can't rely on it in IE. So, I had built this nice clean code that did a feature test for the "input" event and uses it's very clean implementation when present and when not present used this much uglier work-around involving monitoring eight other events. Now, it's busted in IE because the feature test for the "input" event passes so the code attempts to use it, but it's buggy as hell so it doesn't work.

Since these IE bugs show up on user actions, I can't think of any way to devise a javascript feature test to identify the buggy behavior. As such, my only current path is to resort to browser sniffing and refuse to rely on the "input" tag if the browser is IE.

Are there any options here for identifying the buggy behavior in the "input" event besides browser sniffing? If one had to do browser sniffing, is there a way to identify IE by behavior rather than a user agent string that can be freely spoofed and isn't guaranteed to be accurate?

4

2 回答 2

1

jamie-pate 建议这样的事情：

   var broken = false,
        ta = angular.element('<textarea>').on('input', function(evt) {
            broken = true;
        });
    ta.attr('placeholder', 'IESUCKS');

所以你可以在你的代码中检查“支持输入事件并且没有'损坏'”。

见https://github.com/angular/angular.js/issues/2614?source=c

于 2014-01-08T15:15:26.733 回答
0

如果您对跨浏览器的“输入更改”事件感兴趣，这是我的实现：

function onInputChange(domInput, callback) {
    if (domInput.addEventListener) {
        domInput.addEventListener('input', callback, false); // Firefox, etc.
    } else if (domInput.attachEvent) {
        domInput.attachEvent('onpropertychange', callback); // IE
    }
}


使用示例：

var leInput = document.getElementById('myInput');
var leCallback = function () {
    // awesome stuff here
};

onInputChange(leInput, leCallback);


适用于所有浏览器，支持键盘输入和复制/粘贴。

然而，那个被诅咒的 IE9 是个例外，它在我编写上面的代码时并不存在。微软会考虑修复他们的错误吗？:\

于 2012-08-31T15:04:16.153 回答