fix($location): prevent infinite $digest from no trailing slash in IE9

[hamfastgamgee]

fix($location): prevent infinite $digest from no trailing slash in IE9

This fix prevents IE9 from throwing an infinite $digest error when the user accesses the base
URL of the site without a trailing slash. Suppose you owned http://www.mysite.com/app
and had an Angular app hosted in a subdirectory "app". If an IE9 user accessed
http://www.mysite.com/app infinite $digest errors would be thrown on the console, but the app
itself would eventually resolve properly and work fine. Now the infinite $digest errors will
not be thrown.

Closes #11439

[googlebot]

Thanks for your pull request. It looks like this may be your first contribution to a Google open source project, in which case you'll need to sign a Contributor License Agreement (CLA).

📝 Please visit https://cla.developers.google.com/ to sign.

Once you've signed, please reply here (e.g. I signed it!) and we'll verify. Thanks.

---

• If you've already signed a CLA, it's possible we don't have your GitHub username or you're using a different email address. Check your existing CLA data and verify that your email is set on your git commits.
• If you signed the CLA as a corporation, please let us know the company's name.

[hamfastgamgee]

I signed it!

[googlebot]

CLAs look good, thanks!

[hamfastgamgee]

I fully expect this to get some comments as to its correctness. I'm just not sure what the consequences of changing reloadLocation in $browser.url() or trimEmptyHash are, which are where the real problems are found.

[hamfastgamgee]

The general gist is: In the initial pass through $locationWatch(), the afterLocationChange call will either add the trailing slash or add the "otherwise" route (say, /Home) to the URL after the hash. If the latter case, $locationWatch will fire again with $location.$$replace=true, and we need to let that go through to actually change the browser location and get us out of replace mode. But then $locationWatch will fire again (or for the second time if there isn't an "otherwise" route), and this time it will see trimEmptyHash($browser.url()) and trimEmptyHash($location.absUrl()) as unequal and try to change the URL continuously. $browser.url() never ends up updating because sameBase always ends up as true, so we don't actually update reloadLocation which is feeding the $browser.url() getter. So we end up in an infinite recursion of trying to update the URL and failing.

I'm totally open to something that fixes the real problem rather than basically whacking off the infinite recursion. :) I'm pretty sure the reason this is all fine with browsers with the History API is that the sameBase check returns false in one of those iterations and so reloadLocation gets updated properly.

[hamfastgamgee]

Blast. Seems this doesn't fully work anyway. It works on the simplified testcase that's linked off #11439, but it doesn't work in my actual fully fledged app (probably because I have more digest cycles fire). So maybe we have to change $browser.url()'s setter to actually set reloadLocation? I'm not sure why it's doing the sameBase check to begin with, so I'm not sure what the consequences are of changing that.

[hamfastgamgee]

As this one doesn't work, closing pull request.