1899507 - Off-main-thread Worker ScriptLoader

Status: ASSIGNED

(Core :: DOM: Workers, enhancement, P2)

Description

[Eden Chuang[:edenchuang]]

This is part of bug 1672491. This bug is specific to making Worker ScriptLoader work off-main thread. To be more specific, fetching the script off-main thread (maybe through PFetch).

Comment 1

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

Re: PFetch, Note that right now the ScriptLoader in the content-process when working for ServiceWorkers does a Cache API check then falls back to a network fetch. I think we could potentially restructure this to help reduce latency and ideally reduce complexity.

Specifically, we have 2 modes of ServiceWorker script loading:

1. During the install phase, we need to go to the network and add things to the cache if they aren't there.
2. Once installed, we never go to network and if something isn't in the cache, it's an error.

For the installed case, it seems reasonable that we could run a MatchAll() call once on the chrome namespace Cache where we have stored the script pieces. We can then hold these InternalResponses in a map and not have to do any dynamic lookups as the load requests come in. The caveat is that unless we also support dynamic lookups, we would need to hold onto all of the responses other than the root script once the evaluation phase completes because it is still possible to call importScripts() at runtime.

The installation phase could potentially then also use this rep where it would not do queries; we would just add responses to the map as we fetch them. For simplicity, I think this would suggest that we want to do the Cache API calls from the spawned worker rather than having the ServiceWorkerManager pre-emptively do something to cause the parent process to perform the MatchAll and send the results to the newly spawned worker. This is because that we we already have the Cache instance around for the install phase, but also because it doesn't create any new interesting edge-cases.

An interesting question is whether we could use Cache::Add{All} to simplify things, since it also internalizes the fetch; the answer is probably no because it explicitly sets the destination to subresource, but it's worth sanity checking the idea.