"$digest already in progress" when manually changing URL
I have a hybrid AngularJs/Angular app. If I'm on a page, say localhost/home, and I manually edit the URL to localhost/otherPage and hit enter, the browser navigates to the other page, but I get this error:
The error does not occur if:
I navigate to the same page using in-app links
I open a new tab to navigate directly to localhost/otherPage
The stacktrace doesn't show any of my code, so I'm not sure how to debug this. Also, I don't know what difference it makes to the router whether you're "editing" the URL to navigate from home to otherPage as opposed to directly resolving the otherPage URL in a new tab.
Thanks for any help!
From the Docs:
Diagnosing This Error
When you get this error it can be rather daunting to diagnose the cause of the issue. The best course of action is to investigate the stack trace from the error. You need to look for places where $apply or $digest have been called and find the context in which this occurred.
There should be two calls:
The first call is the good $apply/$digest and would normally be triggered by some event near the top of the call stack.
The second call is the bad $apply/$digest and this is the one to investigate.
Once you have identified this call you work your way up the stack to see what the problem is.
If the second call was made in your application code then you should look at why this code has been called from within an $apply/$digest. It may be a simple oversight or maybe it fits with the sync/async scenario described earlier.
If the second call was made inside an AngularJS directive then it is likely that it matches the second programmatic event trigger scenario described earlier. In this case you may need to look further up the tree to what triggered the event in the first place.
For more information, see
AngularJS Error Reference - $rootScope:inprog - Diagnosing This Error
Related
My application has two views, each of these has two routes. When a user change the route of one view, the other should not be changed. This is achieved using sticky states.
One of the routes uses a resolve to go grab something from the server. In my application this is dependent on a route parameter which is simulated in the plunker I put together by returning a random number.
The issue is that the resolve only fires once which means, regardless of the route parameter, it ends up loading the same content and redirecting to the same URL every time.
Worse yet, adding {reload: true} to the state causes this error: state.params.$$keys is not a function. I've started reading the source but figured I should post here in case anyone had seen this before.
I would prefer not to refactor the app to avoid parallel states, and so would appreciate any other suggestions.
You are running into issue #112
https://github.com/christopherthielen/ui-router-extras/issues/112
I built from source and updated your plunk and it seems to be working correclty now when transitioning back and forth between ViewB RouteA and Route B
http://plnkr.co/edit/zpEXaJqXtJPH1pVKPVxj?p=preview
Stupid stackoverflow requires me to add code to the answer since i linked to a forked plunk. there's no code to add
We're having strange, sporadic JavaScript error messages in our production log files (JavaScript errors are logged in the backend):
Uncaught Error: [$compile:tpload] http://errors.angularjs.org/1.2.16/$compile/tpload?p0=modules%2Fsome%2valid-directive-path.tpl.html
The error occurs only with directives. I'm not able to reproduce the errors locally. The templateUrl for the directives are all valid.
The only possible scenario that came to my mind was if the user presses the cancel/stop button in the browser while the page is loading (then i'm able to reproduce the error).
Does anyone have another idea or explanation? Or even a solution :-)
Cheers
Michael
We resolved the issue like this:
Since we are caching our HTML templates with $templateCache using the grunt ngTemplate plugin (https://www.npmjs.com/package/grunt-angular-templates) we do not have the above issues anymore.
Out of interest I was able to recreate this issue. By adding logging to angular I established that when the template load fails it does so with a status of 0 which made me think that the request was actually cancelled. This theory was backed up by the fact that we see no server side errors.
If I emulate a device that cannot support html5 routing and then add an arbitrary query string to the end of the route, it causes an infinite digest loop and in the end the whole page reloads a few times. This in turn was causing the outstanding template requests to be cancelled leading to exactly the errors I was seeing in the logs.
So, for me at least, this is really nothing to do with the loading of the templates, it's just an angular bug (which hopefully is going to be fixed in angular 1.3.8)
I recently posted this question and figured out the direct solution (that being, I was able to cancel a promise/request when the route changed). However, I'm encountering another, related problem that I think belongs in a separate question so here it goes:
I'm able to abort my promise when the route changes just fine (as you can see from the question I linked). However, for some strange reason, any other requests on the other route are delayed when resolving. See my dev tools screenshot below.
Here's the scenario: I load route A, which makes the call to /api/categories and you can see it takes 30ms which is normal. Then I navigate to route B, then before it's done loading I return to route A. When I return, the call to /api/categorySites/1 is cancelled, and you can see when that happens as the gray bar ends. This is done by aborting the promise. However, back on route A again, the call to /api/categories doesn't resolve until that gray dot appears again on the request that was cancelled. That second call to /api/categories shouldn't take 2.23s, it should be closer to 30ms.
What's going on here? I would think the second Route A request would be just as fast as before. I need to get this to work faster. My code is in this question. Let me know if you think I should include it again here. It's hard for me to imagine this isn't a common problem too...
This is an older post but I did look into this and this sounds like eager vs. lazy asynch transition that I read about in Emberjs documentation recently. On your routes (and subsequent aborts) fulfills the promise (completes), moves along to your re-route request.
I believe this can be improved with a state controller.
There is an Angularjs ui-router state controller that might be of use.
Here are example examples.
Angularjs routing documentation (for posterity).
So this is about $routeProvider (Angularjs default) enhanced by $stateProvider (ui-router) to expedite aborted routes.
Hope this is helpful (roughly 312 days later).
The simple thing of calling FB.init (right before </body>) and then FB.getLoginStatus(callback) doesn't fire the callback function.
After some debugging, I think the SDK is stuck in the "loading" (i.e. FB.Auth._loadState == 'loading') phase and never gets to "loaded", so all callbacks are queued until the SDK has loaded.
If I force-fire the "loaded" event during debugging - with FB.Event.fire('FB.loginStatus', 'loaded') in case you're intersted - then the callbacks are invoked correctly.
Extra details that might be relevant:
My app is a facebook iframe app (loaded via apps.facebook.com/myapp)
I'm using IE9. The same behavior happens in Chrome
The app is hosted in http://localhost
What's going on? Why is the SDK never gets to loaded?
Thanks
UPDATE: Just tried it on Chrome and it worked (not sure why it didn't work before). Still doesn't work in IE
I had this same problem in Firefox 3.5 on Windows, but only on the very first log in to the page (probably because it was a slower machine and there was some weird timing issues going on).
I fixed it by forcing FB to refresh the login status cookie every time it checks:
FB.getLoginStatus(callback, true); //second argument forces a refresh from Facebook's server.
Without "force=true", sometimes it wouldn't fire the callback.
I had the exact same problem, and I solved it disabling "Secure Browsing" in the Facebook Security settings. Keeping Secure Browsing on forces the pages as "https", but I had no "Secure Canvas URL" set up, and this gave me a lot of errors in the console as well.
Hope this may help someone :)
In my experience, getLoginStatus() never calls the callback in Firefox when third-party cookies are disabled.
The original poster mentioned his application is hosted on http://localhost. I've never had luck with that, and believe it will cause problems.
Just today, I've had problems where getLoginStatus is not calling the callback on any browser, unless the user is actually connected to the app! I'm hoping this is a bug on facebook's end that they will solve.
Yet another possibility for FB.getLoginStatus not firing its callback is when using a "test" user account that has not been authorized to view that application. Its pretty bad that facebook doesn't give you any error messages.
I have also seen failed callbacks on bad appIds and redirectUrls.
I also ran into this issue specifically in Chrome. I tried calling it on page load and after a user-initiated action with no success.
It turned out that it was not a cross-domain issue. The getLoginStatus() call was being blocked by the Un-Passwordise extension in Chrome. As soon as I disabled the extension, it worked perfectly, even on page load.
More info about this issue here: Chrome-only cross-domain scripting errs in Facebook iFrame App upon FB.Login(..)
I understand that this question is a little old now, but I ran across it searching for solutions.
Double-check what you have set in your Facebook app configuration under the section "Website with Facebook Login". The Site URL domain must match the domain your page with the FB.getLoginStatus (and other related auth Javascript) is served from.
After hours of struggling, I realized that I could not reuse an existing app configuration I had on a new server and had to create a new app to handle the website login for this new server.
The other answers are probably equally valid in your specific case, but since there may be others like me who have struggled for a while on this, hopefully this gives you one other place to check. Making a new app with the correct Site URL was the answer in my particular case.
From the /posts/edit-view I'm submitting a form to the action addCategory in my Post controller.
The action does all the work it has to do, and subsequently calls $this->redirect($this->referer());.
At first sight my app works fine, but I encountered some hickups when moving to a production server. Monitoring the calls in Firebug I see that the action acually returns a 302 Found but the 'Response' is Failed to load source for: http://localhost/xps/posts/addCategory.
This happens on both dev en production servers, only on the production server it makes the redirect flow fail. On both servers the controller actions are executed well: category is added.
Removing all the code in the action results in the same failure. Removing the redirect removes the failure, but that's not getting me anywhere.
A second (though maybe irrelevant) irregularity is that the submit method of the form is identified as PUT in Firebug although I explicitly set it to POST in Cake.
I recently switched from CakePHP 1.3.4 to 1.3.6, but reversing does not change the behavior
I use the RequestHandler, Session and Auth components and call parent::beforeFilter() in beforeFilter().
I also found the following thread http://cakephp.1045679.n5.nabble.com/puzzle-over-activity-td1260972.html It suggests to remove $this->Auth->authorize = 'controller'; but I don't have that stated anywhere anyway.
Does anyone have an idea where to look next?
Just a guess, but if you are using Security component, it might cause problems. Also, sometimes when using the ajax and sessions it can cause problems. Maybe if the page requires sessions, you could try it without sessions and see if it works.
Ok, I found it.
The Failed to load source is still there but is not the cause of failure.
In one of my Behaviors I had a space after ?> which messed up the headers, which made me look into the wrong detail.