$http.get in one instance not firing in IE10

[ThatRendle]

Using 1.1.4, I'm getting some peculiar behavior with a call to $http.get from a callback in IE10. It appears to be related to the evalAsync and nextTick and the serverRequest function not being called as part of a digest. It's fine in Chrome and Firefox (latest of both), and it's fine in IE10 in AngularJS 1.1.3. Oh, and all the other $http.get calls in the application work fine in IE10, it's just this one that's borked.

Code sample below, $scope.login is called from an ng-click directive on an HTML button.

function processLogin(response) {
    $http.get("/xxxxxxxx", { 
        params: { accesstoken: response.session.access_token } 
    })
    .success(function(data) {
        $rootScope.foo = data.foo;
        redirect();
    })
    .error(function(data, status) {
        $window.alert("Error: " + status);
    });

    // Adding this makes it work in IE10
    if (!$scope.$$phase) {
        $scope.$digest();
    }
}

$scope.login = function() {
    $scope.loggingIn = true;
    WL.login({ scope: ["wl.signin", "wl.emails"] }).then(
        function (response) {
            processLogin(response);
        });
};

I see that there have been a lot of changes to the $http code from 1.1.3 to 1.1.4, but I'm not familiar enough with the code to see what might have broken in IE10.

BTW, this applies to IE10 on Windows 7 and 8.

[boushley]

This seems to reproducing for all $http requests as of 1.1.4.

The problem seems to be related to this change: 4ae4681#L1L557

This change changed the way $http worked so that it was scheduled on nextTick instead of firing immediately. This means that if your $http is scheduled from something that doesn't cause a $digest to fire then your request won't be sent. You can verify that this is the behavior you're seeing by clicking on the page a few times (anywhere) and you should see your request go out.

I noticed this initially because I was debugging from the console and was manually making calls into my scope that should trigger an $http request but they didn't fire until I interacted with the page later.

[boushley]

Also, this should affect pretty much all browsers and all platforms. (I'm reproducing it on Chrome / Mac OSX)

[elemoine]

Got hit by that too.

[ThatRendle]

Just so you know, I'll be reopening this issue after the great purge.

[voidfiles]

This is sill an issue in 1.1.5, not sure if this still needs to be tracked or not.

[timruffles]

Having a dependency between $digest and $http seems weird and counter-intuitive to me

[btford]

This has since been fixed in 1.2.x.