Issues in IE10/IE11 when using favorites/bookmarks twice or entering an url manually

[tspaeth]

Hi!

After digging around a lot in the AngularJS-code and also comparing behavior with Backbone etc. in case of routings combined with using bookmarks/favorites in IE10/IE11, there is one thing that leads to a very bad behavior in the IE-browsers together with the History API / event listener structure.

The problem itself is also pretty well described here angular-ui/ui-router#1241

For IE9, the problem is gone since 1.2.24 as the "sync" handling was improved #6976

Unfortunately, for IE10/IE11, the problem still resists. I could drill this down to the following preventDefault event handling:

https://github.com/angular/angular.js/blob/v1.2.x/src/ng/location.js#L705

As soon as this line is removed / commented out, IE10/IE11 behave correctly. Don't ask me why, but this is pretty strange. I wasn't able to oversee the consequences within all browsers except that event bubbling is a bit more and it might lead to a bit of inconsistent behavior.

Need general example code?

Just take these:
AngularJS - http://angular-route-segment.com/src/example/#/section1/2
BackboneJS powered working case - http://demos.9lessons.info/backbone/#block/four/4

• Bookmark one of the states
• navigate away
• click on the bookmark
• navigate away
• click again on the bookmark -> boom

It works if the page is initially called, but not if the bookmarked state was already browsed / called via bookmark. Indications that the event bubbling / intercepting behaves different can be found at http://stackoverflow.com/questions/23349191/event-preventdefault-is-not-working-in-ie-11-for-custom-events and also some other places that IE might behave differently.

Another result of the tests is the fact that the hashchange listener will not get fired if the preventDefault is enabled and that the order of events still seems to be a bit different compared with the other browsers.

[tbosch]

Ok, I think I have a very simple reproduction case that shows that this is a bug in IE10/11: See http://run.plnkr.co/plunks/hFRzW2xCDfC1ig4fMGP2/

In essence, IE does not fire a hashchange/popstate event in the following case:

1. start of with hash #a
2. change hash to #b via pushState
3. change hash back to #a via a normal link/bookmark -> the location is updated but no event is fired

Need to think how we can fix this behavior in Angular...

[tspaeth]

Yes. That reproduction case already shows the problem. And it also counts for the way 1+3+1+2 instead of 1+2+3+4 :-)

IE10+ simply don't fire an event if the last history state is the "next" one after pushing one intermediate state to the history.

Honestly - that's why I filed the defect without a PR - I also wasn't finding a working solution during all experiments besides going back to a timeout-watch-usecase as it is needed for IE9 / HTML4 browsers which is indeed not really cool. But if we won't find another solution, we must probably think about this way to go for all IE versions until Microsoft is able to fix it for future versions.

[tspaeth]

... linking in the case I opened with Microsoft: https://connect.microsoft.com/IE/feedback/details/980398/bookmarks-favorites-event-handling-for-hashbang-urls

[tbosch]

Here is another plunker that is part Angular and part plain links and shows the same problem: http://run.plnkr.co/plunks/PXpjAGB1EJTDmnTGteda/

[tspaeth]

@tbosch the fix LGTM at first sight on testing IE11 :-)
Gonna cross test it with the app developers across next week...
I owe you minimum a beer as developer &helpdesk-time saver, but I think you're not around anymore here in MUC ?! 😀
🍻

[tbosch]

Thanks! No, I am in Mountain View / CA now...

[mgol]

I've just pushed a new version of my pushState PR that changes some things around this code so please have a look at #9027.