$http promises resolving changed in 1.1.4

[ilplotkin]

The following code works successfully in 1.1.3 (and earlier) but does not work in 1.1.4. It does work in 1.1.4 if you replace setTimeout with $timeout or wrap $http.get() into $scope.apply(). Otherwise promise is not resolved until nearest digest cycle. Yes, in general, $q promises resolving is propagated to the nearest digest cycle. But the code below does work in 1.1.3 and docs state that $http callbacks should automatically be wrapped into $apply().

So the question is: where is the correct behavior, 1.1.3 or 1.1.4?
Is it bug introduced in 1.1.4 of bugfix and now the behavior is correct?

function MyCtrl($scope, $http, $timeout) {
   setTimeout(function(){
       $http.get('/echo/json', {data: 'TEST'}).then(function(res){
          $scope.test = res.config.data;
       });
   });
}

[g00fy-]

Maybe this is intentional, so you would be able to collect your requests, and fire them all at once. But since resources don't allow to cancel requests, I don't see any benefit from this.

[honzajde]

+1 for posting this issue. This issue cost me alot of troubles.

[shahmirn]

+1. Causing me issues also with functions being fired by directives and http.get not being called automatically.

[jbthoma]

+1 same here. I didn't see anything about this listed in the breaking changes either, so it feels like a bug.

[mokesmokes]

+1, and the issue (at least in my case) is that the request is not even fired to the server prior to the next digest cycle. Tests fine in 1.1.3 and 1.0.6.

[RobbinHabermehl]

It's not just that the scope isn't updated, $http.get() isn't being executed at all. See http://jsfiddle.net/TKDJC/ for a demonstration. Initiating a digest cycle manually by calling $scope.$digest() after the HTTP request resolves this issue, see http://jsfiddle.net/TKDJC/1/.

This issue hasn't been fixed in version 1.1.5.

[valentinkostadinov]

+1 breaking tons of stuff, definitely breakage from previous versions, intentional or not. Is this being worked on, or is it intentional?

[mokesmokes]

@valentinkostadinov , see #2431, which was replied to by the Angular team yesterday. Seems intentional - or rather, a known byproduct of design changes. However, the ramifications of these changes are not documented, AFAICT, in the latest code drop.

[btford]

As part of our effort to clean out old issues, this issue is being automatically closed since it has been inactivite for over two months.

Please try the newest versions of Angular (1.0.8 and 1.2.0-rc.1), and if the issue persists, comment below so we can discuss it.

Thanks!