Yesterday, a bug was discovered in an app I maintain: a single text input was disabled in IE11 when it shouldn't be. I immediately jumped in, believing it to be a mis-fire with an ng-disabled
statement. Nearly two hours later, zero progress was made. This seemed like such a simple fix on first blush!
It made no sense. The placeholder
text was set as the value
. The ng-model
binding didn't update in the controller on text entry. The submit
action did nothing when I hit enter, but worked on clicking the submit button for the form. The input fired a test function from an ng-click
, but didn't from ng-focus
or ng-blur
. I decided to cut my losses and leave it for the morning.
Today, after (not really) sleeping on it, I took another look. I broadened my search terms, hoping to get hint of a solution. A number of searches later, the secret words ended up being: angularjs strange form behavior ie11
.
Embarassingly, that (in hindsight) obvious phrase led me to the official AngularJS Developer Guide, which describes exactly what I was seeing in my app:
Using the
disabled
attribute on an element that has descendant form controls can result in unexpected behavior in Internet Explorer 11. For example, the value of descendant input elements withng-model
will not reflect the model (or changes to the model), and the value of theplaceholder
attribute will be inserted as the input's value. Descendant select elements will also be inoperable, as if they had thedisabled
attribute applied to them, which may not be the intended effect. To work around this unexpected behavior, 1) avoid using the identifierdisabled
for custom attribute directives that are on elements with descendant form controls, and 2) avoid usingdisabled
as an identifier for an attribute passed to a custom directive that has descendant form controls.—AngularJS: Developer Guide: Internet Explorer Compatibility
Upon examining the parent components, I found the source of my pain. Somebody on my team (of one) had used disabled
as an identifier for a binding on the parent component, which falls into the category of custom directives that have descendant form controls! By simply renaming the binding to isDisabled
and using the attribute is-disabled
, the entire issue disappeared.
Let my over-confidence be a warning to others: Read. The. F***ing. Manual.
Top comments (1)
Happens all the time to me as well. You make this big detour to come back to the manual. You will be bitten again :-) Who has time for the manual?