On Thu Sep 12 16:51:28 2024 +0000, Gabriel Ivăncescu wrote:
For sync XHRs it seems pretty complicated due to gecko internals. For example, my idea was to process tasks at a given "depth level" only, or those pushed on such depth level (which gets changed on a sync XHR, and otherwise is zero). This means only sync XHR tasks get processed in the sync XHR. In theory it sounds fine and correct, but the sync XHR tests fail. 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… So maybe we should just execute all tasks at given depth level or before it—but not after. This won't be completely correct for sync XHRs but I think this is a fringe case that doesn't happen in practice? The async operation would be correct wrt. task nesting, and also sync XHRs keep their current behavior when no nested message loops happen, which is important as well. (currently battling test failures due to an issue I don't understand but yeah)
BTW note that it's more than just the sync XHR io tasks themselves. As I said, even tasks related to prior async XHRs in the xhr.js tests had to be processed for some reason (which have nothing to do with the sync XHR), else it hanged. That's why I gave up trying to "only process tasks related to sync XHR" (IO or otherwise) which was my idea originally that failed, and went with something simpler for such a niche case.