Created attachment 549286[details]
testRequestAnimationFrame.html
User Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:5.0) Gecko/20100101 Firefox/5.0
Build ID: 20110615151330
Steps to reproduce:
I was using mozRequestAnimationFrame to schedule a tick, replacing the old behavior of using setInterval/setTimeout
Actual results:
mozRequestAnimationFrame seems to have the ability to jump into currently running JavaScript code and disturbs the callstack. I have been under the impression JS/DOM code should be running in a single thread context, instead of other code being able to run until the current context has completed.
I've attached a test page. The test code schedules a callback either using setTimeout or mozRequestAnimationFrame, then makes 10 synchronous XHR calls. If I'm using setTimeout, the callback is correctly called after the current function has returned. If I'm using mozRequestAnimationFrame however, it will be called before the function has returned.
There actually seems to be a related bug in setTimeout. If you modify the attachment and modify line 72/73 by switching the SendXHR to be the alert instead, you will see that the callback is called immediately before all 10 alerts have been triggered.

Created attachment 550012[details][diff][review]
Proposed fix
Maybe I should just add a boolean tracking whether we're in a state where we should be registered with the refresh driver, so the revoking code can also move the checks into the revoke method. Then the posting code could use that boolean too. Anyway, let me know.

> Shouldn't you check also if timeouts are suppressed?
> (or if top->mModalStateDepth is >0)
Good question. When are timeouts suppressed but events not suppressed?
I'd rather not mess with modal state depth unless we change everything to follow it.
> should we have a new method IsEventHandlingEnabled or something like that
We could do that, yes. Olli, any objections?

If the page is in modal state, timeouts won't run.
See nsGlobalWindow::RunTimeout.
"If you modify the attachment and modify line 72/73 by switching the SendXHR to be the alert instead, you will see that the callback is called immediately before all 10 alerts have been triggered" sounds like a bug to investigate.

> sounds like a bug to investigate
For what it's worth, I can't reproduce that part. So yeah, the modal state check seems to be working.
> This surely doesn't compile?
Indeed. I was sure I'd compiled this, but clearly not!
Olli, how do you feel about comment 15?

(In reply to comment #15)
> Perhaps we should fix comment #13 by suppressing events in non-chrome
> documents while there's a modal dialog up.
Why only in non-chrome? We sure want to have the same behavior in chrome.

I'm not entirely convinced we do. I think if chrome is rendering something it wants to keep rendering it even if there's a modal alert up. Declarative animations sure don't stop when that happens!
We need to break the web behavior due to the braindead non-reentrancy expectations websites have, for now, but in the future I fully expect that we may want to implement sync XHR in content by blocking the content thread. That's clearly not the way to go for chrome....