That's because those tests first create two async XHRs and then a sync XHR. It appears that gecko will simply hang if we don't process the async XHR tasks in the sync XHR message loop…
I guess it's about use of tasks in `nsio.c`.
In general, it's not tasks themselves that we need to block here, but rather script (or host) visible notifications. We don't want to stall other bindings during sync XHR just like we don't want to stop repainting GUI. What we want is to give the script an impression that it's not processed. And yeah, such synchronous operations in a middle of otherwise asynchronous environment are broken by design, that's why sync XHRs are deprecated. That said, it's probably fine if we don't get it exactly right.