1663590 - XHR.timeout is affected by long tasks

Status: RESOLVED INVALID

(Core :: DOM: Networking, defect, P3)

Description

[Samuel]

User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_6) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/85.0.4183.83 Safari/537.36

Steps to reproduce:

A zip file with the front and back-end needed to reproduce this issue is attached.

1. Open the zip file, and serve that folder (in mac you can run "http-serve") and visit the index.html file.
2. The folder has a "server.js" file. Run it with "node server.js."
3. Refresh multiple times, and you will see that sometimes the timeout callback is called, even though it shouldn't (console will log "timeout!").

What the script and server reproduce:

1. The timeout is set to 1000ms.
2. The request is made.
3. A blocking script is running for 2000ms (a while loop).
4. The server responds in 100ms (concurrently to step 3).
5. The timeout callback is called, and the request is canceled.

Actual results:

The request is canceled and the timeout callback is called.

Expected results:

The request should not be canceled (chrome behaves correctly, safari has the same issue).
It seems like the timer counting the time of the request is running on the main thread and therefore affected by long tasks, this should not be the case.

Comment 1

[Florencia Di Ciocco, NI to vbalducci]

Hi Samuel,

You forgot the attachment :)

Regards, Flor.

Comment 2

[Samuel]

Attachment: timeout-bug.zip

The forgotten attachment....

Comment 3

[Samuel]

Thanks, Flor!
I added the attachment.
Here is the fixed bug in webkit for reference: https://bugs.webkit.org/show_bug.cgi?id=216266

Comment 4

[Florencia Di Ciocco, NI to vbalducci]

Hi Samuel,

Thanks for the details. I was able to reproduce the bug on Windows 10 on the following versions:

	Release 80.0 (64-bit) and Nightly 82.0a1 (2020-09-20) (64-bit).

I believe that the severity is S4 or S3. I've chosen a component. If you consider that there's another component that's more proper for this case you may change it.

Best regards, Flor.

Comment 5

[Kagami Rosylight [:saschanaz] (they/them)]

Seems the last active person in XHR was :smaug. Mind taking a look?

Comment 6

[Olli Pettay [:smaug][[e-mail]]]

Timer should count time, it is not specific to to any threads. So if main thread has some long running JS, xhr timeout should fire.
The spec has:

Run these steps in parallel:
Wait until either req’s done flag is set or
the timeout attribute value number of milliseconds has passed since these steps started
while timeout attribute value is not zero.
If req’s done flag is unset, then set the timed out flag and terminate fetching.

https://xhr.spec.whatwg.org/#dom-xmlhttprequest-send

Comment 7

[Olli Pettay [:smaug][[e-mail]]]

oh, hmm
perhaps
"If req’s done flag is unset, then set the timed out flag and terminate fetching. "

Comment 8

[Olli Pettay [:smaug][[e-mail]]]

The spec is inherently racy here, since it is possible that done flag isn't set before timed out flag. Nothing defines the order of those.

Could you perhaps file a spec issue on this?

Comment 9

[Kershaw Chang [:kershaw]]

(In reply to Olli Pettay [:smaug] from comment #8)

The spec is inherently racy here, since it is possible that done flag isn't set before timed out flag. Nothing defines the order of those.

Could you perhaps file a spec issue on this?

Anne, could you help to do this?

Comment 10

[Anne (:annevk)]

I don't understand the race you are concerned about. The timed out flag is only set when the done flag is unset (for asynchronous XHR). (For synchronous XHR there is no done flag.) So there is a race between the request being done and it timing out, but that is needed for the feature to work. 😊

Comment 11

[Olli Pettay [:smaug][[e-mail]]]

Ah, isn't this just about the order of timer and network response, which isn't guaranteed.
"Wait until either req’s done flag is set or this’s timeout is not 0 and this’s timeout milliseconds have passed since now. "