XHR event-timeout-order.htm should be flaky given the current spec-test.

[wisniewskit]

Is there anything in the spec text actually backing up the final assertion in event-timeout-order.htm? (which I believe is checking that a setTimeout task queued after a send() will not run before a short-timeout XHR's onloadend fires:

xhr.addEventListener("loadend", function() { test.done() });
xhr.send("Test Message");
test.step_timeout(() => {
  assert_unreached("ontimeout not called.");
}, 10);

Based on the spec-text, it should be easily possible that the setTimeout could run before handle response end-of-body task for the timed-out XHR runs, which would make this final check spurious.

I remember writing this test-file, but I don't recall if I added that final check for a legitimate reason or just assumed it made sense. @annevk, do you know if that assertion is necessary for known web compat issues?

I don't currently have the time to investigate what other browsers do, and they currently don't even get to that assertion (according to the WPT dashboard).

Note: this also affects event-timeout.htm

[annevk]

I'm not sure. It does seem somewhat nice if we could guarantee that a timeout of 5 runs before one of 10.

[wisniewskit]

@annevk, I just ran into this again while doing some more work on refactoring Firefox's XHR implementation.

But I don't really think this is an issue anymore. Gecko is currently passing because it does very little between receiving the notification that the XHR should timeout and actually dispatching the timeout/etc events.

By contrast my new implementation was just telling the fetch to abort, then waiting for the fetch to signal that the response had ended before calling the request error steps. This of course took much longer, causing intermittent failures. I don't see those failures anymore after short-circuiting it to passively abort and just call the error steps right away.

It seems to me that other implementations would also pass this if they do the same. As such I'll close this bug, since I do agree that it would be nice for the timeouts to fire in this order.