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