Fetch a worker's main script before creating its settings object - #12837
Fetch a worker's main script before creating its settings object#12837shannonbooth wants to merge 4 commits into
Conversation
Use a reserved environment for the initial fetch, then create the worker environment settings object once the final response URL is known.
cb5837a to
7d2db87
Compare
| object, and false otherwise.</p></li> | ||
|
|
||
| <li><p>Let <var>owner</var> be the <span>relevant owner to add</span> given <var>outside | ||
| settings</var>.</p></li> |
There was a problem hiding this comment.
Since we do this after fetching, can this capture a different document due to navigation? Perhaps when the Window object is reused as with initial about:blank?
| </li> | ||
|
|
||
| <li><p>Set <var>request</var>'s <span data-x="concept-request-reserved-client">reserved | ||
| client</span> to <var>reservedEnvironment</var>.</p></li> |
There was a problem hiding this comment.
If we're changing this to be an environment, we'll need corresponding changes to https://fetch.spec.whatwg.org/#concept-request-reserved-client and probably also File API and Service Workers.
There was a problem hiding this comment.
Thanks, I had missed this, firstly because LB doesn't implement service workers, and second reason seemingly as Fetch/FileAPI integration seems to have a type issue currently as obtain a blob object only accepts an ESO but fetch can pass through a plain environment. Just changing fileapi types over to environment seems correct as blob partitioning should apply to navigations too based on https://github.com/web-platform-tests/wpt/blob/master/FileAPI/BlobURL/cross-partition-navigation.https.html. I had wrongly originally implemented that AO to accept a plain environment, presumably other implementations do that also (though this is a somewhat recent change).
| <p>Otherwise:</p> | ||
|
|
||
| <ol> | ||
| <li><p>Let <var>moduleFetchOptions</var> be a <span>script fetch options</span> whose <span |
There was a problem hiding this comment.
Should this not repurpose fetch a worklet/module worker script graph somehow?
There was a problem hiding this comment.
I think it would be good. The problem which makes this tricky is that fetch a worklet/module worker script graph takes an ESO. To fix this, we'll need to restructure those algorithms to not take an ESO which I think is possible but from what I gather does have a lot more fallout
2 participants
Use a reserved environment for the initial fetch, then create the worker
environment settings object once the final response URL is known.
Fixes: #11340
Fixes: #3771
Will cause conflicts with #12580, but I think these MRs both help each other in terms of Worker global initialization.
(See WHATWG Working Mode: Changes for more details.)
/webappapis.html ( diff )
/workers.html ( diff )