IE10 fires input event when a placeholder is defined so that form element is in dirty instead of pristine state

[jupiterplanet]

Input elements in AngularJS can be in pristine state meaning that the input element's value hasn't been modified yet by the user. In this case error messages can be hidden although validation fails because the input field is empty.

AngularJS uses different measures to determine if the value in an input element has changed. It listens to the input event for all browsers supporting this event with the exception of IE9 as this browser does not implement this event correctly.

However, as it turns out IE10 also has implementations faults. If a placeholder is defined on an input element IE10 fires this event when the placeholder is set during DOM loading and when it is removed when the user clicks into the input field so that error messages which depend on the pristine condition are displayed although the user has not yet modified the input's value.

Open the following plunk with IE10 to see this behavior:
http://plnkr.co/LqlkhtIPPEwgP0znR7vz

Click into the e-mail input field and the error message displays although the input's value has not changed yet.

In all other browsers (Chrome, IE9, Firefox) the error message is not displayed.

A workaround is to not use the input event just like for IE9.

config(['$provide', function($provide) {
        $provide.decorator('$sniffer', ['$delegate', function($sniffer) {
            var msie = parseInt((/msie (\d+)/.exec(angular.lowercase(navigator.userAgent)) || [])[1], 10);
            var _hasEvent = $sniffer.hasEvent;
            $sniffer.hasEvent = function(event) {
                if (event === 'input' && msie === 10) {
                 return false;
                }    
                _hasEvent.call(this, event);
            }
            return $sniffer;
        }]);
    }]).

[theNailz]

This fix works, but is far from good. Is this a browser bug, or a Angular/jQuery bug?

[theNailz]

Can be reproduced: http://jsfiddle.net/eY62X/1/

[Guuz]

👍

[theNailz]

Looks like it's fixed in IE11, and is browser related.

[Guuz]

I just tested it in IE and its not fixed...
An input element becomes dirty as soon as its focussed. Unlike Chrome for example where you have to type in it first.
A textarea becomes dirty right away without touching it.

[jamie-pate]

may be related to #5025 ?

[jamie-pate]

Better sniff code:

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

[Guuz]

lol :) nice one @jamie-pate!

[WalterWeidner]

BUMP. This really needs to be fixed by the angular team.

[caitp]

Angular isn't necessarily capable of fixing bugs in IE, @WalterWeidner. How would you propose fixing it? Do we say "oh, the text value is identical to the value of the placeholder attribute, therefore it must not be a real value lets just ignore it"? Because that approach seems like it would cause much worse problems.

I'll submit a fix for it but honestly I expect any fix for this is going to cause more regressions than the fix was worth

[jamie-pate]

The fix would be to sniff for this problem and not use the input event just like for IE9. (as mentioned at the top of the thread) We all wish that ie10 had actually ended the constant stream of ie workarounds but It seems like they will continue to be needed (though at least the fire hose seems to have been reduced to a garden hose)

[WalterWeidner]

I agree that it is an IE problem but I think it would be better for it to be accounted for in angular code rather than in every single user's module configuration. This way the code will be less likely to break when we switch to future versions of angular.

[caitp]

The issue with sniffing this is, the event (at least on IE10 standards mode) is not triggered synchronously, and I can't seem to get it to trigger before DOMContentLoaded/onload. So the issue here is that by the time we need to use the sniffed value, it's unavailable (unless text inputs are in templates imported by asynchronous directives).

Further, we have no way of knowing that the input event was triggered by a placeholder, as the input event doesn't give us any feedback about what caused it. So it's probably a lost cause to try to deal with this.

There are so many problems with the entire issue that it's honestly probably not even worth trying. IE10 is still a big chunk of the browser market, but it's on a steep decline, while IE11 is on the rise.

This kind of works, but I have no guarantees that it doesn't break other browsers, and it relies on the UA string so we have no guarantee that it will even fix the issue in every possible configuration of IE.

    if (msie && event && event.type === 'input' && !value && value === lastValue &&
      element.prop('placeholder')) {
      return;
    }

in the listener.