Worker blocks on the main thread on XHR/fetch requests

NEW
Unassigned

Status

()

P3
normal
2 years ago
7 months ago

People

(Reporter: BenWa, Unassigned)

Tracking

(Depends on: 1 bug, Blocks: 1 bug, {parity-chrome})

unspecified
parity-chrome
Points:
---
Dependency tree / graph

Firefox Tracking Flags

(platform-rel +)

Details

(Whiteboard: [platform-rel-Facebook])

(Reporter)

Description

2 years ago
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.
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.
Blocks: 1328622
Depends on: 1015466
(Reporter)

Comment 2

2 years ago
Sounds good. Thanks for the update.
Priority: -- → P3
(Reporter)

Comment 3

2 years ago
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]
You need to log in before you can comment on or make changes to this bug.