Repository navigation
Issues in IE10/IE11 when using favorites/bookmarks twice or entering an url manually #9143
Description
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.
Activity
tbosch commentedon Oct 2, 2014
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:
#a#bviapushState#avia a normal link/bookmark -> the location is updated but no event is firedNeed to think how we can fix this behavior in Angular...
tspaeth commentedon Oct 2, 2014
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 commentedon Oct 2, 2014
... linking in the case I opened with Microsoft: https://connect.microsoft.com/IE/feedback/details/980398/bookmarks-favorites-event-handling-for-hashbang-urls
tbosch commentedon Oct 3, 2014
Here is another plunker that is part Angular and part plain links and shows the same problem: http://run.plnkr.co/plunks/PXpjAGB1EJTDmnTGteda/
fix($browser): don’t use history api when only the hash changes
tspaeth commentedon Oct 3, 2014
@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 commentedon Oct 3, 2014
Thanks! No, I am in Mountain View / CA now...
mgol commentedon Oct 4, 2014
I've just pushed a new version of my
pushStatePR that changes some things around this code so please have a look at #9027.fix($browser): don’t use history api when only the hash changes
fix($browser): don’t use history api when only the hash changes