ngAttr* directive issue with href attribute in IE

[plalx]

This fixes an issue where any form of ng-attr-href directive wasn't correctly processed in IE.

I am not sure why there was the special IE condition for the href attribute but node.getAttribute(name, 2) doesn't make any sense since it's trying to fetch the binding value from the attribute we are actually trying to populate.

I have removed the special case handling and every unit tests are still passing.

Issue Plunkr

[IgorMinar]

I'm sorry, but I wasn't able to verify your CLA signature. CLA signature is required for any code contributions to AngularJS.

Please sign our CLA and ensure that the CLA signature email address and the email address in this PR's commits match.

If you signed the CLA as a corporation, please let me know the company's name.

Thanks a bunch!

PS: If you signed the CLA in the past then most likely the email addresses don't match. Please sign the CLA again or update the email address in the commit of this PR.
PS2: If you are a Googler, please sign the CLA as well to simplify the CLA verification process.

[petebacondarwin]

From looking at the history there appears to have been an issue with an old IE (possibly IE7) regarding accessing the href attribute through the element.attributes collection. You had to get it via element.getAttribute instead and decode it, too.

Since we are no longer testing on IE7, this may be why the tests are no longer failing...

[petebacondarwin]

See 259c2bb

[petebacondarwin]

From http://msdn.microsoft.com/en-us/library/ie/ms536429(v=vs.85).aspx:

Internet Explorer 8 and later. In IE7 Standards mode and IE5 (Quirks) mode, attributes that represent URLs and file paths return the same value whether you retrieve them as a DOM property or as a content attribute (using getAttribute). Some attributes return relative URLs, whereas others always return a fully qualified URL. In IE8 mode, DOM attributes always return fully qualified URLs for URL attributes; to retrieve the attribute value as specified in the content, use getAttribute. The following attributes return URLs: action, background, BaseHref, cite, codeBase, data, dynsrc, href, longDesc, lowsrc, pluginspage, profile, src, url, and vrml.

So it seems that this is for IE8 support. Perhaps the check should be (msie<9)?

[petebacondarwin]

Here is a fork that does this: http://plnkr.co/edit/xtAaQJYBFr7LDZad7onQ?p=preview

[petebacondarwin]

I can confirm that this works on IE11 and IE9. I'll knock up a branch and send it to the CI server for further testing.

[petebacondarwin]

Hmm. So the new spec fails on IE8 too! @plalx I think you are right. We should just drop the whole exceptional case!

[plalx]

@IgorMinar I signed it for my next contribution ;)

@petebacondarwin Thanks for fixing. In theory it shouldn't have been much of a big concern since there's the ng-href directive which didin't suffer that issue. But now that we can bind any attributes using ngAttr* we may ask why we need these attribute-specific directives (other than backward compatibility). I haven't investigated but if there are other valid reasons like execution priority, perhaps a warning should be logged when using the generic ngAttr* form for these?