Open Bug 1330826 Opened 8 years ago Updated 2 years ago

Worker blocks on the main thread on XHR/fetch requests


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




Tracking Status
platform-rel --- +


(Reporter: BenWa, Unassigned)


(Depends on 1 open bug, Blocks 1 open bug)


(Keywords: parity-chrome, Whiteboard: [platform-rel-Facebook][necko-triaged])

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:

Chrome is working on fixing the queuing issue as well.
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.
Depends on: 1015466
Sounds good. Thanks for the update.
Priority: -- → P3
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.
Whiteboard: platform-rel-Facebook → platform-rel-Facebook, parity-chrome
platform-rel: --- → ?
Whiteboard: platform-rel-Facebook, parity-chrome → [platform-rel-Facebook], parity-chrome
platform-rel: ? → +
Mass bug change to replace various 'parity' whiteboard flags with the new canonical keywords. (See bug 1443764 comment 13.)
Keywords: parity-chrome
Whiteboard: [platform-rel-Facebook], parity-chrome → [platform-rel-Facebook],
Whiteboard: [platform-rel-Facebook], → [platform-rel-Facebook]
Whiteboard: [platform-rel-Facebook] → [platform-rel-Facebook][qf]
Blocks: 1522316
Whiteboard: [platform-rel-Facebook][qf] → [platform-rel-Facebook]

bug 1522316 was marked as qf:p1

See Also: → 1531511
Component: DOM: Workers → DOM: Networking
Priority: P3 → --

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.

Depends on: omt-networking
Priority: -- → P2
Whiteboard: [platform-rel-Facebook] → [platform-rel-Facebook][necko-triaged]
Priority: P2 → P3

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

Severity: normal → S3
You need to log in before you can comment on or make changes to this bug.