19:46 | <Noam Rosenthal> | Maybe I'm supposed to run processCustomFetchResponse with a network error and null |
19:48 | <Noam Rosenthal> | Ah actually not. It's supposed to return a network error instead of the actual response |
19:49 | <Noam Rosenthal> | those "fetch hooks" are like a post-processor to whatever fetch gave you |
19:49 | <Noam Rosenthal> | you fetch the script like you do for a normal worker, and then run the "perform a fetch hook" as defined in the service worker spec on the response |
19:51 | <Noam Rosenthal> | (Sorry, I mean it's a processor that replaces what fetch gives you) |
19:52 | <akaster> | Yeah I think I have it correct here <https://github.com/LadybirdBrowser/ladybird/pull/1866/files#diff-ae24ad31836c730f2992e34539836a76a794aa52041ac31ac00d4c96dd1bf53dR213>; or at least , correct-ish. The thing I don't like is waiting in perform the fetch hook for the processResponse for the fetch to trigger. I feel like I should be back-propogating the fetch controller so it can be aborted or something |
19:53 | <akaster> | I'm grabbing the perform custom fetch response in my fetch hook and using it as the process response consume body hook in the fetch algorithm input, same as what the worker impl does. Just, causing my fetch hook to return a network error to influence how the algorithm from "fetch a worker script" behaves |
19:54 | <akaster> | ... Definitely in need of a spec update here once I actually create a service worker process and prove that the script runs as an MVP |
19:56 | <Noam Rosenthal> | Yeah I think I have it correct here <https://github.com/LadybirdBrowser/ladybird/pull/1866/files#diff-ae24ad31836c730f2992e34539836a76a794aa52041ac31ac00d4c96dd1bf53dR213>; or at least , correct-ish. The thing I don't like is waiting in perform the fetch hook for the processResponse for the fetch to trigger. I feel like I should be back-propogating the fetch controller so it can be aborted or something processResponseConsumeBody ). I'm not sure if aborting in this case is web-observable |
19:58 | <akaster> | Makes sense. I think if it was to be consistent with "run a worker" the steps should say that we do all these checks in process response consume body, and then run the process custom fetch response passed in by "fetch a classic worker script" afterwards (still in process response consume body) |
19:59 | <Noam Rosenthal> | Yea I have a faint memory of refactoring scripts to use processResponseConsumeBody myself a few years ago, and I probably neglected service-worker fetching |
20:01 | <akaster> | I'm still a bit confused about the time traveling environment settings object I'm supposed to invent. I guess I'll have to create some faked-out ESO once I implement setting up the service worker global and environment settings and understand what properties are relevant |
20:04 | <Noam Rosenthal> | Ah you mean https://w3c.github.io/ServiceWorker/#issue-02e2fe82 I think |
20:05 | <akaster> | Yeah both of those issues correspond to fixmes in my PR there 🤔 |
20:06 | <akaster> | They're basically saying that fetch wants the context for who will run the script, but we don't have the context yet because we haven't started the service worker process yet. So, hand wave and hax incoming |
20:08 | <Noam Rosenthal> | hehe gotcha. I think this can be similar to the environment created for yet-to-be-navigated-to documents but it would require a lot of care to spec correctly |
23:33 | <gingeh_> | Hello, how should isomorphic decoding handle non-ASCII bytes (>0x7F)? |