Bug: Changing the location outside of $location causes infdig and/or resets the original url

[arcanis]

Hi,

As said in the title, if the location is changed from outside the $location service (but inside a digest cycle, and especially inside a $q.then callback), then Angular will break and there is two possible outcome, apparently random (maybe some kind of race condition?) :

• Either Angular break with an infinite digest loop (and an empty watcher list)
• Or Angular will reset the URL to the old one by going into this code branch

Here is a minimal showcase to reproduce this issue :

<script src="https://cdnjs.cloudflare.com/ajax/libs/angular.js/1.3.13/angular.js"></script>

<script>
    angular.module( 'testApp', [ ] ).controller( 'testController', function ( $location, $q, $scope, $window ) {
        $scope.triggerThing = function ( ) {
            $q.when( ).then( function ( ) {
                $window.history.pushState( { }, null, '#/testfoo' );
                $scope.$broadcast( 'test' );
            } );
        };
    } );
</script>

<div ng-app="testApp">
    <div ng-controller="testController">
        <a ng-click="triggerThing()">Trigger</a>
    </div>
</div>

[arcanis]

I noticed something : wrapping the pushState inside a $timeout call workaround the issue. However, using $scope.$evalAsync doesn't. Weird.

[Narretz]

What's your use case for changing the location without the $location service, but inside an angular app?

[arcanis]

@Narretz I need the location service to use the History API (pushState / replaceState), but also the hash URLs. For example, using path('/foo'), I need the underlying service to do a pushState('#/foo') (rather than pushState('/foo'), which is the current behavior).

Now, as rational for this, I have to use the hash routing because my application is an offline app built around an AppCache, and updating an master entry (ie. page) from the appcache requires to explicitely list it inside the cache manifest. I cannot list every possible path inside this manifest, and so I have to keep a single master entry (index.html), and use the hash routing to load the correct url.

Since Angular does not allow me to do this (enabling the HTML5 mode would disable the hash routing, and leaving the HTML5 mode would prevent me from using the state objects, which I need), I was relying on a custom $location service, which was working fine until I hit this bug.

[hgfischer]

I think I'm getting into this same issue.

I have a special application that deals with a special hash code, present in the URL. We use ##! to avoid conflicts with ng-route.

Inside this application there is a link to replace location that conditionally replaces location to another page of the same domain. We used "$window.location.replace()" and it was working until we updated from 1.2.26 to 1.2.28.

I tried changing $window.location.replace() for $location.replace() and got the same Infinite $digest Loop error in the console. The error only happens when this ##! is present in the URL.

[arcanis]

Ping @Narretz ? Is there enough info ? The best for me would be to be able to use the $location service as specified (hashbang routing, set with pushstate instead of directly in window.location.hash), but at the very least, solving the bug would be great.

[Narretz]

A plnkr (which we can download and test) is always helpful to get an idea of the problem. Generally, Angular currently doesn't play very well with custom history / location manipulation, so I refrain from calling this a bug for now.

[ShayMatasaro]

I have been running into the same issue when using ui-router and $state.go with simple url parmaters
the location bar resets to the root
adding $timeout fixed the location bar issue , but now the browser back button interchnages between the correct url and the root url, examining the browser history doesnt even show the base url on the list

[arcanis]

@Narretz The code in the first post is the true minimal showcase. Here is a plunker and its run page.

But what I'd really like (and the rational is detailed in my previous post) is to be able to use both a hash-based url and the history API. I get this bug because I'm trying to workaround Angular by creating a new service with the described behavior, and I'd like to avoid that.

[apolishch]

@Narretz We have the following usecase for using window.location directly.

We have a large angular application broken up into multiple single page applications utilizing ui-router internally. As such we have (for example).
app.com/activities/#/11111/edit
app.com/projects/#/11111/edit
etc.

Now when we want to navigate from one application to another we are forced to use window.location directly as both $location and ui-router rely on being in the HTML5 fragment of the URL.

Doing so will trigger this exception in production with some regularity.

Now, lets look at the official angular documentation:
https://docs.angularjs.org/guide/$location#what-does-it-not-do-
To reload the page after changing the URL, use the lower-level API, $window.location.href.

[Saurbaum]

I see this same problem if I navigate using the URL bar in IE directly.

navigating to #/database/home which is my controller to link the current user to a home page the controller in there works only once. Every subsequent attempt using either dynamic links, manually editing the URL in the browser or a navigate call from an ActiveX control (yes I want that dead but it's stuck in there now) results in this infinite digest loop.

http://stackoverflow.com/questions/30776131/angular-controller-loads-only-the-first-time-in-ie

[angular-tools]

I'm also facing the same issue where calling window.history.pushState causes a 10 $digest() iterations reached. Aborting! error.

It only happens when I include the $location in controller, otherwise everything works as expected.

P.S. Using window.history.pushState inside a $timeout function does not cause the error (but then nothing happens to the URL also if $location is included)

[gkalpak]

This is also fixed by #15561 (updated plnkr).

[gkalpak]

Actually, it is not exactly fixed by #15561. #15561 fixes the infinite digest error, but in certain cases it still fails to update $location. The problem with using history.pushState() directly is that it does not emit any event (e.g. hashchange or popstate), so Angular fails to detect that there has been an external change in the URL 😞

[gkalpak]

I updated #15561 to also fix this issue (although probably not in the way you might want 😁).
Now external URL/history changes that happen during the digest are picked up correctly and propagated to $location (updated plnkr).

[sktocha]

I have app that using history(outside angular). Angular app without html5mode.. so when url changed seriously it reloading page, otherwise it return old url. It's because initialUrl, appBase, appBaseNoFile have old value. I suggest add some reloadInitPath method to LocationHashbangUrl or app or take them from $rootScope.

[mattkerle]

Just want to say thank you, we've had a bug in our system for two years that was unfixable, updates to the address via $location.search() were getting discarded on one module and we couldn't figure out why, the only thing we knew was that a POST was running in the same Digest cycle, we used a $timeout to workaround it as well.

Thanks to this issue I found the exact code in angular that handles the address updating and realised that angular-block-ui was preventing the location change from happening because the POST was triggering it. Two years and many grey hairs later IT'S FIXED!

thanks guys!

[quisse]

@sktocha found a solution for your problem?