| 06:17 | <annevk> | Thanks krosylight! |
| 08:10 | Ms2ger 💉💉 | denies everything |
| 09:38 | <annevk> | Jake Archibald: so one thing that strikes me is that there's no forwarding of cancelation to a fetch initiated by the service worker |
| 09:39 | <Jake Archibald> | annevk: in which direction? As in, which side is listening for the cancelation, and which side is cancelling? |
| 09:39 | <annevk> | Jake Archibald: so if a document fetches A and the service worker fetches B and returns that, when exactly will it listen to aborting of A? |
| 09:40 | <Jake Archibald> | annevk: if the stream is cancelled, that part works right? For stuff that happens before that, I thought fetchEvent.request.signal could be used as an indicator |
| 09:40 | <annevk> | I guess only if it reuses the Request object in some manner, although I'm not sure how well that is defined |
| 09:41 | <annevk> | I think it there might be some race issues, but canceling the stream probably works, yeah |
| 09:43 | <annevk> | Noam Rosenthal: I think one thing that might influence the design of the interaction with service workers is what we want to do with timing |
| 09:43 | <annevk> | Noam Rosenthal: I'm not entirely sure what information needs to be exchanged |
| 09:43 | <annevk> | Noam Rosenthal: if that information would ideally be on a "service worker fetch event controller", I guess that's what we should add |
| 09:44 | <annevk> | Noam Rosenthal: as per your suggestion, and fetch would forward an abort to that controller |
| 09:45 | <annevk> | (It's a little weird that in JavaScript the cancelation is managed by AbortSignal on the Request, but that doesn't encompass all types of aborting that might happen, so maybe this is okay.) |
| 09:54 | <Noam Rosenthal> | annevk: regarding timing, going forward there shouldn't be interaction. It's part of why I want to make things more explicit there |
| 09:55 | <Noam Rosenthal> | only a fetch would keep its timing info and report it. later of course we can add more things to the controller. |
| 09:56 | <Noam Rosenthal> | (the service worker timing is only relevant to navigation timing, and in that case the timing is not part of a fetch but is queried directly from the service worker) |
| 09:56 | <annevk> | Noam Rosenthal: oh, I thought we also needed to expose Cache API timing and things like that |
| 09:57 | <Noam Rosenthal> | for the fetch, we need to expose "finalize and report timing info" |
| 09:57 | <Noam Rosenthal> | cache state can be read from the response |
| 09:57 | <Noam Rosenthal> | there's nothing new we need to expose from service worker |
| 09:58 | <annevk> | Noam Rosenthal: so that means that if there is service worker the timing information ends up being mostly opaque, right? |
| 09:58 | <Noam Rosenthal> | it's reported inside the service worker |
| 09:58 | <Noam Rosenthal> | so you can do performance.getEntries from within service worker code etc |
| 09:58 | <Noam Rosenthal> | but it's opaque to the caller fetch |
| 09:59 | <Noam Rosenthal> | it felt like exposing that information twice mainly creates ambiguities |
| 10:00 | <Noam Rosenthal> | ... that's why I didn't want that information on response which is a strange object that gets passed around and stored |
| 10:00 | <annevk> | thanks, sgtm |
| 10:01 | <annevk> | I added a very brief summary of our options for service workers to your PR |
| 10:06 | <Noam Rosenthal> | what's "UB territory"? :) |
| 10:13 | <annevk> | UB being undefined behavior |
| 10:13 | <Noam Rosenthal> | AH, TIL |
| 14:04 | <annevk> | Luca Casonato: fwiw, the cookie thing is blocked on getting someone from Chrome or Safari to chime in; hopefully it's clear from the prose and tests that it's not a whole lot of additional work |
| 14:05 | <annevk> | Luca Casonato: I have a couple more nits on the PR, but might as well wait until we have the higher-level checkboxes done |
| 14:06 | <annevk> | (And I'm also willing to push a fixup for that myself in due course) |
| 17:39 | <hober> | Luca Casonato: fwiw, the cookie thing is blocked on getting someone from Chrome or Safari to chime in; hopefully it's clear from the prose and tests that it's not a whole lot of additional work |
| 17:41 | <annevk> | hober: heya, https://github.com/whatwg/fetch/pull/1346 |
| 23:41 | <Jeffrey Yasskin> | I just opened https://webidl.spec.whatwg.org/ for the first time, and I definitely miss the table-of-contents-on-the-side from the old stylesheet. |