| 10:54 | <Noam Rosenthal> | akaster: might be relevant, but fetch also accepts a reserved client in the cases where you don't have a Realm yet (e.g. you're navigating to a new document, loading a new worker) |
| 10:55 | <Noam Rosenthal> | akaster: https://html.spec.whatwg.org/multipage/workers.html#run-a-worker, search for reserved client |
| 14:58 | <Dominic Farolino> | I'm not entirely sure what fields/algorithms from the environment settings object "fetch a classic worker script" and "fetch a module script graph" need, but I'm hoping it's only like, the origin and url and other easily serializable data? But Fetch Request explicitly says that its client must be an environment settings object or null |
| 15:02 | <akaster> | Hmm. But in that case we want the inside settings object of the worker. We also set the reserved client to the inside settings. The issue I'm seeing with our implementation right now is down to checks about same origin, about CORS, etc when overriding things set to "client" with those from the outside settings |
| 15:02 | <annevk> | akaster: that sounds about right. Ideally we'd convert a client to such a concrete struct, but I never really got there and don't want to make the time for it at the moment. |
| 15:03 | <akaster> | And by issues I mean, I called fetch with "inside settings" as the client and it doesn't work well 😅 |
| 15:05 | <annevk> | I think ideally we'd rewrite most specs to call fetch from a JS thread (i.e., not from in parallel) and then have fetch snapshot state that it needs early on as well as keep a handle around in order to post tasks back (that may end up going nowhere due to race conditions). And then have a dedicated entry point for calling fetch from in parallel where you are responsible for handing fetch the correct state. |
| 15:06 | <annevk> | By-and-large things should be like this already, but there's certainly exceptions. |
| 15:11 | <akaster> | So it sounds like there probably wouldn't be an issue with replacing the request's client with some record that has origin, URL, some policy flags, etc, as anything that needs to post tasks or events or generally do callbacks should be using the reserved client? Or should be handled through other hooks that are already in place. |
| 15:11 | <akaster> | At least, at the implementation level anyway |
| 15:57 | <annevk> | akaster: yeah, that should be fine. And in fact implementations will have to do something like that as some policies are mutable and fetch will have to operate on the policy as it was at the time of fetching. Though note that policy flags can get quite involved (CSP for instance). |
| 16:06 | <akaster> | Yeah, we don't implement CSP at all yet 😅 |
| 16:07 | <akaster> | Though it is curious that it seems the fetch algorithm wants to post tasks to the fetch client's global object directly, rather than asking if there's a reserved client. Maybe reserved client isn't as much of an escape hatch as I was hoping. |
| 16:08 | <akaster> | Escape hatch from having to do the fetch in the agent for the window that opened the worker, I mean. Rather than doing it in the agent for the worker. |
| 18:12 | <farre> | annevk: [Bug 1741034](https://bugzilla.mozilla.org/show_bug.cgi?id=1741034), the thing about sending a load event for same site cross-origin navigation. You don't happen to know what WebKit does |
| 18:22 | <farre> | annevk: [Bug 1741034](https://bugzilla.mozilla.org/show_bug.cgi?id=1741034), the thing about sending a load event for same site cross-origin navigation. You don't happen to know what WebKit does |
| 19:06 | <annevk> | I don't. Someone(tm) should prolly make some WPTs. |
| 20:03 | <farre> | That would be me I guess :) |