nsIThread.processNextEvent is a great way to simplify code doing lots of asynchronous calls. Instead of using callbacks that will make the code hard to follow, you write: while (not done) currentThread.processNextEvent(true); This works fine - as long as there is only one "synchronous" action at a time. If you use that pattern throughout application you will easily get into trouble, when the second "synchronous" action starts pumping messages is prevents the older one from finishing. I attach a testcase that exemplifies this (needs to run from chrome://). When you click "start action 1", it starts pumping messages waiting for you to click "stop action 1" (set a flag). As soon as you click that button, that action actually finishes. Now you can click "start action 1" and then "start action 2" - clicking "stop action 1" will have no effect now, the loop only stop if you click "stop action 2". This affects nsIEventTarget.dispatch(DISPATCH_SYNC) as well as XMLHttpRequest, whatever starts first has to wait for all "synchronous" action that started afterwards. So even if the first synchronous XMLHttpRequest took 1 second, code execution will still be blocked for 20 seconds if the second request takes that time.