1351231 - Implement PFetch protocol and backing FetchService to allow Workers to request fetches without involving the main thread of their process

Status: ASSIGNED

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

Description

[Ben Kelly [:bkelly, not reviewing]]

Currently fetch() using nsIChannel on the main thread in the current process.  This means that a worker thread (like service worker) can hit main thread jank when it tries to perform a network request.  This is particularly bad for service workers since delaying the fetch() may in turn delay the network result for the main page load.

The network team is working on making nsIChannel support PBackground so it can be used OMT.  That will probably take a long time to fully happen, however.

In addition, our service worker e10s refactor will move the service worker instances to a new process.  That will also take some time to happen.  Its also possible the memory overhead of this new process will be too large.

An alternative we could do in the short term would be to implement a separate PBackground actor just for fetch().  We already support serializing Request and Response objects across IPC in the Cache API.  In addition, Andrea recently landed parent-to-child AutoIPCStream support.  Between these it might be easy to use PBackground to go to parent, proxy to main thread there, and then create the nsIChannel.

If we did this, though, we would not be able to fully remove the current implementation.  A PBackground fetch() would bypass the child-side service worker intercept today.  We would only be able to use it in fetch() calls from within the service worker global itself.  Eventually we could remove the old fetch() implementation after SWM is moved to the parent.

Comment 1

[Ben Kelly [:bkelly, not reviewing]]

We may want to do this even with the necko changes.  Right now I think they are only making OnDataAvailable() work OMT which means we still need to touch main thread for On(Start|Stop)Request().

Another factor to consider, though, is we would need to do something special for devtools.  It currently requires nsIChannel in order to show up in the network monitor.

Comment 2

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

Note: From a conversation with Dragana on Feb 14, 2019, I understand the plan is to make AsyncOpen, OnStart, and OnStop work off the main thread, so this bug probably wants to be duped.

Comment 3

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

See https://bugzilla.mozilla.org/show_bug.cgi?id=1613912#c4 for the plan.

Comment 4

[Anne (:annevk)]

Does this block parsing worklets as module scripts, i.e., bug 1572644?

Comment 5

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

(In reply to Anne (:annevk) from comment #4)

Does this block parsing worklets as module scripts, i.e., bug 1572644?

No. One could implement bug 1311726 while still performing the current "let's do all the network stuff on the main thread" behavior. Noting that right now the worklet script loader just assumes the one single invocation of WorkletFetchHandler that feeds into the module compilation.

The network-on-the-main-thread uses could then subsequently be replaced with PFetch later on.

Comment 6

[Eden Chuang[:edenchuang]]

Attachment: Bug 1351231 - Preference for PFetch. r=#dom-worker-reviewers.

Comment 7

[Eden Chuang[:edenchuang]]

Attachment: Bug 1351231 - Support conversation between InternalRequest and IPCInternalRequest. r=#dom-worker-reviewers

Depends on D138812

Comment 8

[Eden Chuang[:edenchuang]]

Attachment: Bug 1351231 - Preference for PFetch. r=#dom-worker-reviewers.

Comment 9

[Eden Chuang[:edenchuang]]

Attachment: Bug 1351231 - PFetch protocol declaration and implementation. r=#dom-worker-reviewers

Depends on D138813

Comment 10

[Eden Chuang[:edenchuang]]

Attachment: Bug 1351231 - FetchService integration for PFetch. r=#dom-worker-reviewers

Depends on D142436

Comment 11

[Eden Chuang[:edenchuang]]

Attachment: Bug 1351231 - Integrate FetchChild into Fetch.cpp r=#dom-worker-reviewers

Depends on D142437