Bug 230294 – XMLHttpRequest Progress Even Not Firing for Requests Finished under 100Ms

• Status: RESOLVED
• Resolution: CONFIGURATION CHANGED
• Component: WebKit Misc.

[OpenSpeedTest.com]

To reproduce this issue use https://hub.docker.com/u/openspeedtest on a 10Gbps network (Wired)(I used 10GbE M1 Mac Mini)
or
https://apps.apple.com/in/app/openspeedtest-server/id1579499874?mt=12 on a Mac With high speed connectivity

#1 Issue found when tested 10 Gbps Network on my M1 MacMini with 10GbE

XHR progress event not firing when a request that is completed under 100 Ms. So programs depends on Progress even will not work correctly.
Up to 2.5 Gbps this issue is not found in Wired Network on MacOS. 

#2 Issue found on iPhone XR when test LAN speed on WiFi. Upload Progress even was not firing on a connection speed that was 400Mbps. 


Why XHR progress event is not firing on VERY FAST connection or a request that is finished under 100 Ms?
This is expected Behavior?

[Sam Sneddon [:gsnedders]]

Are we talking about progress events for the request upload or the response download?

How often, and when, do you expect the progress event to fire?

The spec says:

> If not roughly 50ms have passed since these steps were last invoked, then return.

So on the face of it, it should fire roughly every 50ms.

That said, going back to your root issue, I think the problem here is WebKit doesn't fire it _at all_ if it the request happens too quickly? That does sound like a bug.

[Radar WebKit Bug Importer]

<rdar://problem/83143221>

[OpenSpeedTest.com]

I found this issue Two Months Ago and handled this issue via XHR OnLoad event which is just a workaround. but it was working fine. And this is happening only on speed which is 2.5Gbps or higher. So most people will not run in to this issue right now. But Clearly this is going to break some functions that is dependent on XHR progress event. 

Someone from twitter contacted me and reported he found same Behavior on his iPhone XR. But For me unable to reproduce this on my iPhone 6S. I thought XR was more powerful and capable for doing that just like a mac. But turns out it was a problem with his server configuration. 

But this problem still exists on a Mac with Safari and i can reproduce this if i execute UPLOAD request on local host or on a very high speed connection that is 2.5Gbps or Higher.

So this problem i found is for UPLOAD PROGRESS.

You said it is firing every 50ms which is good. but in my case i added a delay of 100Ms delay for new requests and it worked without issue. So i think if there is pending request (For a speed test there will be always few pending requests will be there) it will not fire upload progress event and quickly go to OnLoad event.

So currently my program logic will check for upload progress event and if it was not fired. It will add the payload data size manually in the OnLoad event. 

I think even if a request that started and finished under 10Ms should get at-least one progress event. So programs that depends on Progress even will not break. 

For 2.5Gbps, 5Gbps and 10Gbps connection Chrome is working without any issue.

[Alexey Proskuryakov]

This seems like desirable and correct behavior at a first glance. Running extra JavaScript code for such a quick load seems unnecessary and potentially bad for performance.

[OpenSpeedTest.com]

Depend on progress event alone is a bad idea right? 
It may or may not fire. Especially for request load under 100 or 50Ms.
Can you give more scenarios where  progress event will not fire?

[Sam Sneddon [:gsnedders]]

(In reply to OpenSpeedTest.com from comment #3)
> You said it is firing every 50ms which is good. but in my case i added a
> delay of 100Ms delay for new requests and it worked without issue. So i
> think if there is pending request (For a speed test there will be always few
> pending requests will be there) it will not fire upload progress event and
> quickly go to OnLoad event.

Note I was quoting the spec, not describing current WebKit behaviour.


(In reply to Alexey Proskuryakov from comment #4)
> This seems like desirable and correct behavior at a first glance. Running
> extra JavaScript code for such a quick load seems unnecessary and
> potentially bad for performance.

Definitely per spec it should always fire at least once.

It also seems like something where we're likely to end up with a worse user experience (one can trivially imagine plenty of sites failing to test the case when it never fires).

[OpenSpeedTest.com]

Then this is a bug?

"Definitely per spec it should always fire at least once."

Clearly this is not happening on Latest Safari for requests that is finished under 100 or 50 Ms.

[Anne van Kesteren]

It looks like this got fixed by this commit: https://github.com/WebKit/WebKit/commit/7cfb84288e855e7c3bf1f79692523a06f450ab0b