-
Notifications
You must be signed in to change notification settings - Fork 27.5k
$location runs into infinite digest under certain circumstances #1417
Comments
Here is a jsFiddle that reproduces the issue: http://jsfiddle.net/dbinit/tMmKf/ |
I also ran into this bug recently. For me it happened while testing in IE8 with |
I confirm this bug for AngularJS 1.1.0 and IE9. |
This is also happening to me in Chrome (Version 22.0.1229.94 m), when using window.history.pushState in response to a button click. Angular version: 1.0.2. |
Any update to this? Giving us some IE9 headaches. |
I am also experiencing this in IE9. Any update? |
having the same problem. Still no fix for this? |
For what it's worth, I was having this issue in IE9 and Android and here is what I did:
var buggyAndroid = parseInt((/android (\d+)/.exec(window.navigator.userAgent.toLowerCase()) || [])[1], 10) < 4; |
In my case, I wasn't using $location at all. It was just getting pulled in by $anchorScroll, which is used by ngInclude. I wasn't using $anchorScroll either, so I just did this to remove the dependency:
If you're using $anchorScroll you could probably just null out $location instead. |
I'm running into this and I don't have explicit watchers and I don't import $location.
Any ideas? |
Here is an example where the initial page load fails and reloads after throwing the above error. Note: jsfiddle doesn't handle any angular routing, so the rendered view is a blank jsfiddle. Also, nothing will happen at all on an html5 supported browser. My understanding is that the page is going to need to refresh to convert the url from html5 mode to hash mode (adding the "#" http://jsfiddle.net/#/v7HG5/). In my case this is fine, but it should handle its errors. |
Also problem with Any news on this issue? Right now the team is contemplating setting |
I've managed to reduce the occurance of this bug significantly by using $location.path() and $location.search() instead of manually using location.href. Hope that helps someone else. |
@gaiottino were you using angular for routing or an external plugin? because i would love to see the solution for app that uses an external plugin but want to watch the url change |
@leonzinger I was iterating an app which relied on crossroads.js and Handlebars to Angular. It worked great for Chrome/FF/Safari, but IE would have $digest problems described above. I've removed crossroads.js now in favor of using Angular for routing but with a patch I'm hoping will make it's way into master: #1901 |
@gaiottino Thanks a lot for the answer, i would love to see it working with an outside routing library though... |
@leonzinger the only part which took some investigation was how to compile Angular specific code. Once you render html with Angular markup you need to compile it. I don't have any code to show but using https://github.com/leshill/handlebars_assets it was basically template = HandlebarsTemplates[template_name]
html = template()
$(selector).append(html)
compile(selector) if html.has('ng-controller') Where the compile function is compile: (selector) ->
app = angular.element(document)
compiler = app.injector().get('$compile')
scope = app.scope()
elements = angular.element("#{selector} [ng-controller]")
if elements.exists()
for el in elements
element = angular.element(el)
template = compiler(element)
html = template(scope)
scope.$apply() if(!scope.$$phase) If you plan to render html dynamically you should also destroy any previous controllers that are no longer used destroy: (selector) ->
elements = $(selector).find('[ng-controller]')
for element in elements
app = angular.element(element)
if app
scope = app.scope()
scope.$destroy() if scope The app was bootstrapped manually using $ ->
angular.bootstrap(document) |
In case it is useful... I was hitting the "10 $digest() iterations reached. Aborting!" error when using $window.history.back(); with IE9 (works fine in other browsers of course). I got it to work by using:
|
Thats not a very good solution though. It isn't guaranteed to work on slower machines. I have ran into a similar issue where I get the digest iteration error on some phonegap devices but not others. Quite bizare. Looking for a work around |
I'm seeing this as well. Using IE9 and I'm not even using history. I just use $location.search()['searchTerm'] in one of my controllers so that i can capture something from the query string and act on it. Works fine in ff with html5mode=true. in ie9 with mode true it spins then goes to the IIS home page and puts a # in my url. With mode set to false it doesn't perform the qs search. |
I am seeing this on IE9 with angular 1.0.5. Is this by any chance fixed on 1.1.3? Or is there a known workaround? |
We are experiencing the same error on IE9 when invoking $window.history.back(). We tried with plain "window" and it's the same. At this fiddle http://jsfiddle.net/DGbNp/ you can see the first two functions from the Angular error "stack trace" from IE console error. (We edited the output to remove double quotes and \n 's). |
I'm also seeing this on IE9 with angular 1.0.5. Sadly this is a show stopper for our team as far as moving ahead with angular. :-( |
Bump, I have the exactly same thing on FF16 and Chrome22 with Angular1.0.5. |
+1 - 1.1.3 / IE9 |
Had the same issue recently, manually commenting out 577 - 611 in https://github.com/angular/angular.js/blob/master/src/ng/location.js did do the trick for me... What about adding an option to dis-/enable $location's watch on browser url completely.. something like: angular.module('myApp', []).config('$locationProvider', function($locationProvider) {
$locationProvider.disable(); //disables/removes all watchers on browser url change
}) |
+1 IE8/9 |
|
@lord2800 Thanks for mentioning that - I have struggled with the exact same issue for hours now. In my case, I have two apps bootstrapped using Running angular v1.2.16, Chrome 35.0.1916.153. |
@swlasse that's exactly what we ended up doing as well. Glad to be of help! |
This watch generates the same error on pageload. It's a simple pagination watch on a forum topic show page. $scope.$watch("postPagination.cur", function(newVal, oldVal) {
if (angular.isDefined(newVal) && newVal && (newVal !== oldVal)) {
$window.history.pushState({
page: newVal,
prev: oldVal
}, "", $scope.currentPath + "?page=" + newVal);
$scope.loadPosts(newVal);
}
}); |
Okay, I couldn't find an exact answer, so this is what worked for me (hopefully it helps someone else). This is occurring for me in AngularJS v1.2.22. In IE8 / IE9 I get the The solution for me was to simply use $location. Ex: Instead of: window.location = '/#!/test123/'; Use: $location.path('test123').replace(); |
I have this issue with the 1.3.0-rc.0 version. |
@rbygrave Thank you, your workaround works for me with delay = 500 ms. 100 ms doesn't help. |
I encountered this issue in the context of manually bootstrapping my app, as I forgot to remove hg-app directive, which basically leads to location watch infinite digest breakdown. So I can case you are encountering this problem under uncertain circumstances better double check that first. |
I am running into this problem when doing my own routing. ngRoute has been removed from the app. I run something like
I could do with some way to stop Angular from listening to anchor clicks too, which I guess is related to this problem as it's listening for location changes so that it can fire $locationChangeStart etc. |
Also having this same issue using Angular UI Router... |
@BlueHayes @richardm did you try what I mentioned? If you attempt to change the url/history without $location angular goes haywire. |
What fixed the infinite redirecting issue for us was removing the "otherwise" block, from our routeProvider. We have a unique situation of 2 angularJS applications running in the same page, so this fix might not be the fix for everyone. |
This problem appeared with migration to 1.3 and was related to injecting $location into a service. It was happily working before the change. Used the suggestion by @swlasse (cheers) to get around the problem. |
dca2317, which closed that issue, does not fix the problem raised by @IgorMinar in this issue's initial description. @IgorMinar, the issue you described in #1417 (using "Angular in an existing project that makes use of html5 history (goog.history.Html5History for example) is not IE-specific at all. This is a major issue. This makes Angular in my way, even when I don't use the |
The only workaround I've found involves monkey-patching the |
In my app I don't use
|
Thank you, @smirnovigor ! Well, it works and it doesn't work too. With UI-Router it doesn't replace the url with a new state's url... |
Hmm, I did simple think and it seems me to that it really helped. I do some redirection after a user logged in and simply wrapping my redirect call into setTimeout method help with the $location event loop. setTimeout(function({ Not elegant, but it works! |
You guys are so awesome changing window.replace to $location.path(url_step2_view); worked amazingly. THANKSSSSSSS!!!!!!!!!! |
…ortsatte att försöka öppna nya rapporter efter att användaren blivit utloggad. Lösning enligt diskussion här: angular/angular.js#1417
Thanks @azachar! Your timeout workaround helped in my case. |
@azachar's timeout workaround worked for me too. |
@smirnovigor You are the MAN! Been working on this for 2 days! The decorator works everyone! |
@caviles You didn't solve a bug, you weren't using $location. This bug is about $location. |
In my case, I used window.location.href = 'xxx', when I changed it to $location.path(), It worked fine. |
when adding Angular to an existing project that makes use of html5 history. Whenever the url is changed outside of Angular, the next $digest to run produces this error:
Error: 10 $digest() iterations reached. Aborting!
Watchers fired in the last 5 iterations: [["fn: $locationWatch; newVal: 8; oldVal: 7"],["fn: $locationWatch; newVal: 9; oldVal: 8"],["fn: $locationWatch; newVal: 10; oldVal: 9"],["fn: $locationWatch; newVal: 11; oldVal: 10"],["fn: $locationWatch; newVal: 12; oldVal: 11"]]
I have my own routing in place, using goog.history.Html5History. I was trying to include some Angular stuff on a single page (works), but when the page changes, the first subsequent $apply produces the above error. It looks like the $location service is getting out of sync with the browser.
$locationWatch expects the $location service to be updated first, followed by the browser. But when I pushState to the browser directly, the $location service still has the old url.
The sad thing is that $location is not being used directly by this app, nor is $route. It's ngInclude, that depends on $anchorScroll, which depends on $location - maybe fixing this dependency should be a separate issue... (to be investigated)
The text was updated successfully, but these errors were encountered: