Timeout callback can occur in the middle of a digest cycle in Firefox

[pkaminski]

It appears that, in Firefox only, certain actions cause it to process the timeout queue on top of the current call stack. If the current call is in a digest cycle, and a $timeout with invokeApply=true gets triggered, this results in a $apply already in progress error.

See http://plnkr.co/edit/9V1jQSaszbjrt9F5ACjk?p=preview for a repro that uses window.open to trigger timeout processing. If you click on the button you'll see the following sequence in the console:

"before window open" script.js:6
"timeout" script.js:5
"Error: [$rootScope:inprog] $apply already in progress
http://errors.angularjs.org/1.3.1/$rootScope/inprog?p0=%24apply
minErr/<@http://code.angularjs.org/1.3.1/angular.js:80:12
beginPhase@http://code.angularjs.org/1.3.1/angular.js:14463:1
$RootScopeProvider/this.$get</Scope.prototype.$apply@http://code.angularjs.org/1.3.1/angular.js:14207:11
timeout/timeoutId<@http://code.angularjs.org/1.3.1/angular.js:15945:25
completeOutstandingRequest@http://code.angularjs.org/1.3.1/angular.js:4842:7
Browser/self.defer/timeoutId<@http://code.angularjs.org/1.3.1/angular.js:5215:7
$scope.click@http://run.plnkr.co/AFImpHzuwgSHuYUW/script.js:7:5
$parseFunctionCall@http://code.angularjs.org/1.3.1/angular.js:12114:15
ngEventHandler/</callback@http://code.angularjs.org/1.3.1/angular.js:22548:17
$RootScopeProvider/this.$get</Scope.prototype.$eval@http://code.angularjs.org/1.3.1/angular.js:14110:16
$RootScopeProvider/this.$get</Scope.prototype.$apply@http://code.angularjs.org/1.3.1/angular.js:14208:18
ngEventHandler/<@http://code.angularjs.org/1.3.1/angular.js:22553:17
createEventHandler/eventHandler@http://code.angularjs.org/1.3.1/angular.js:2979:9
" angular.js:11339

"after window open"

Tested on Firefox 33.1.1 in Windows 7 and OS X with Angular 1.3.1, but I've observed the same thing on older versions of both Firefox and Angular so it's not a regression. I used window.open to trigger timeout processing for the repro but I have reason to believe that other operations can do it too. I haven't seen this happen in Chrome or any other browser.

I don't know the formal spec of setTimeout well enough to guess whether this is a bug in Firefox or not, but in either case it seems like something that's worth guarding against in Angular.

[petebacondarwin]

This looks like a pain to fix. It looks like Firefox is trying to be clever and batch up things that are likely to run around the same time into a single call stack. A timeout of more than 80ms on my machine seems to allow the timeout to happen in a separate thread.

[pkaminski]

Note that the "set timeout and immediately open window" setup in the repro is very artificial, so working around the issue by raising the timeout is not practical. What actually happens in my app is that I set a multi-second (or -minute) timeout somewhere unrelated, and then if the user takes an action at just the right time the app crashes. I've already taken all my window.open calls out of the digest as a workaround but I still see occasional crashes, which is why I think that there's something else that can cause Firefox to trigger timeout processing too.

[rwilliams-scottlogic]

This is affecting our application.

We are receiving a bursty flow of messages over a web socket, and handing them to a web worker for (reasonably expensive) processing immediately. Now the general advice is to run anything that comes in to the application in a $rootScope.$apply, but we want to avoid trying to digest 50+ times a second. So when the worker postMessages back to the window with the result, we run some service code outside of $rootScope.$apply and then call a throttled version of $rootScope.$apply to limit our digest rate.

We are seeing in Firefox, that if the throttled function (underscore.js, which uses setTimeout) is scheduled to run but the main thread is busy in a digest at the time, Firefox tries to run the $rootScope.$apply on top of the current call stack - causing the error seen above.

[petebacondarwin]

@rwilliams-scottlogic - I think you might benefit in your use case from using $scope.applyAsync. See http://blog.thoughtram.io/angularjs/2015/01/14/exploring-angular-1.3-speed-up-with-applyAsync.html

[pkaminski]

@petebacondarwin It looks like $applyAsync still uses setTimeout (based on the linked article), so it would remain susceptible to this bug. In my app, I ended up monkeypatching $digest and $apply to skip the digest if it was already in progress. I hate messing with deep infrastructure like that but so far it seems to be holding up...

[gkalpak]

How about $evalAsync (which is kind of a "safe $apply") ?

[lgalfaso]

If multiple threads are executed on the same context, then other things on top of digest can go wrong. Is there a bug report at Firefox?

[rwilliams-scottlogic]

I found a 2006 "resolved incomplete" bug for "Functions registered with setTimeout may be executed in the same stack on MacOS X": https://bugzilla.mozilla.org/show_bug.cgi?id=354347

I've opened a new issue for what we are now seeing: https://bugzilla.mozilla.org/show_bug.cgi?id=1127236.

It also appears that "message" event handlers attached to web workers can be run on top of the current call stack, if the main thread is busy when the worker posts a message to the window.