1330826 - Worker blocks on the main thread on XHR/fetch requests

Status: NEW

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

Description

[Benoit Girard (:BenWa)]

Probably a dupe but I can't find it and I want to make sure this is known.

When doing an XHR request 'new XMLHttpRequest()' from a worker the request will fully block on main thread.

This is bad because the worker has to wait for the main thread to flush all its events before starting the XHR request. This means that moving code to a web worker can lead to a significant slowdown because you have to wait for one main thread event loop flush per request.

Chrome's behavior here is a bit better. They wont block on the request but it wont start until the main thread has flush. This means that at least you can queue several request at once instead of one at a time:

https://bugs.chromium.org/p/chromium/issues/detail?id=443374

Chrome is working on fixing the queuing issue as well.

Comment 1

[Ben Kelly [:bkelly, not reviewing]]

Yea, this is a known limitation of nsIChannel at the moment.  I believe necko team has some thoughts to fix in bug 1015466.

Also, be aware other APIs do this as well.  For example, if you do a new URL() it will also do a sync loop to the main thread.  This is due to nsIURI requiring main thread.

As I'm sure you know these long standing legacy restrictions are super annoying and we want to fix them.  Just takes time unfortunately.

Also, our current e10s refactor plans for service worker will mitigate the problem in the medium term.  We plan to spawn a separate service worker specific process.  So the main thread will be pretty much empty for service workers performing these functions.  See bug 1231208.

Comment 2

[Benoit Girard (:BenWa)]

Sounds good. Thanks for the update.

Comment 3

[Benoit Girard (:BenWa)]

Thanks for the update. I understand that this is not an easy fix but I'm glad it's on the radar.

I do think this bug should be higher than P3. Because of this issue web workers (and SW until they're moved) are not a useful API to improve responsiveness and it limits their use case severely.

Facebook is trying to use Web & Service Worker for improving responsiveness and to move work off the main thread but this limitation is causing these features to be a regression on Firefox. Without this fixed we can't use APIs for what were intended.

I assume other web developers might be running into the same issues and not seeing the performance they expect. However DevTools doesn't expose enough data to really pin-point that Web & Service Workers are blocking on the main thread. This issue is likely under reported as a result.

Comment 4

[Jonathan Watt [:jwatt]]

Mass bug change to replace various 'parity' whiteboard flags with the new canonical keywords. (See bug 1443764 comment 13.)

Comment 5

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

bug 1522316 was marked as qf:p1

Comment 6

[Andrew Sutherland [:asuth] (he/him)]

Note: From a conversation with Dragana on Feb 14, 2019, I understand the Necko team plan is to make AsyncOpen, OnStart, and OnStop work off the main thread.

Comment 7

[Stephen Donner [:stephend] Not actively reading bugmail]

Mass-removing myself from cc; search for 12b9dfe4-ece3-40dc-8d23-60e179f64ac1 or any reasonable part thereof, to mass-delete these notifications (and sorry!)