| 08:25 | <Noam Rosenthal> | annevk: for https://github.com/whatwg/infra/pull/709 (using infra for sanitizer), do we need infra to allow embedders to define an "equality" operator and how all the algorithms like "contains" use it? or is it enough that the sanitizer section says something to the effect of "items in this lists are considered equal when..." |
| 08:27 | <annevk> | Noam Rosenthal: there is an open issue on equality we need to get to at some point. I think I would accept Sanitizer without that getting defined, but we should note it in the HTML source that it needs to be done. |
| 08:27 | <annevk> | Open issue against Infra that is. |
| 08:27 | <Noam Rosenthal> | SG, I'll link the open issue from a note |
| 08:27 | <annevk> | I guess zcorpan also needs to say if that's okay. |
| 08:27 | <annevk> | I don't think we want a note. Either XXX or a source comment. |
| 08:28 | <Noam Rosenthal> | Yea I meant one of these things |
| 08:28 | <Noam Rosenthal> | Maybe I'll get a chance to send an infra PR for equality operators at some point (without blocking sanitizer work) |
| 10:35 | <zcorpan> | Sounds good |
| 13:18 | <annevk> | sideshowbarker: not sure if you're still awake, but we're getting a 404 when running the HTML checker for about the last two hours it seems https://github.com/whatwg/infra/actions |
| 13:20 | <annevk> | sideshowbarker: ah, and per https://github.com/validator/validator/commits it seems you pushed something that broke CI there; I guess that adds up |
| 13:31 | <rego> | hi, some of you are coming to the Web Engines Hackfest in June 15-17, so we were thinking if it'd be a good idea to arrange a WHATNOT meeting there, it could be an extraordinary one or we can try to move one of the usual ones to fit into the hackfest days/times; that would give more people the chance to see how these meetings happen; WDYT? if you feel it's a good idea, should we fill an issue at https://github.com/whatwg/html/issues/ to start organizing it? |
| 14:29 | <foolip> | Are we having trouble with the HTML checker? I have a build failure in https://github.com/whatwg/fullscreen/actions/runs/25492816064/job/74805083038?pr=232 |
| 14:33 | <annevk> | foolip: yes, see above. |
| 14:34 | <Dominic Farolino> | Am I correct in thinking that a request's "destination" does not get copied over when you perform new Request(fetchEvent.request) in a Service Worker? From reading https://fetch.spec.whatwg.org/#dom-request I think that's right, but that seemed odd so I can't tell if I'm missing something. |
| 14:35 | <annevk> | Yes, we can't let the service worker pretend what request it's making. |
| 14:36 | <Dominic Farolino> | Wait sorry can you clarify "pretend what request it's making"? Sec-Fetch-Dest derived from destination is copied over (just not exposed to JS), right? |
| 14:43 | <Dominic Farolino> | Ah I guess that's OK since they'll get re-generated anyways when the SW re-fetches the new request? (Man, service workers are complicated.) |
| 14:44 | <annevk> | Sec-Fetch-Dest is always computed from scratch for each HTTP request |
| 14:45 | <Dominic Farolino> | Right, so as long as we strip the request's destination concept member when we copy requests, we ensure that Sec-Fetch-Dest is effectively "wiped" (or at least doesn't retain its old privileges) if the SW tries to copy/fetch the request on its own. Is that right? |
| 15:02 | <Noam Rosenthal> | Yea all the service workers fetch() requests are regular fetches because you can cache them/share them/use them for any destination later on |
| 15:08 | <Dominic Farolino> | So the original fetch event's request retains its destination, and can be forwarded straight to fetch() and its Sec-Fetch-Dest will be generated accordingly, in a way that no script-constructed Request could, right? But that changes right when you copy the original request into a new Request—"destination" is lost and therefore you can't preserve Sec-Fetch-Dest etc. Is my mental model of this right? |
| 15:13 | <annevk> | When you call fetch() I think destination will be reset. |
| 15:15 | <Dominic Farolino> | Ah I think you're right, because fetch() delegates to the Request ctor right away, which doesn't carry over destination. |
| 15:16 | <Noam Rosenthal> | right, it's a rule of thumb that you can't use the same request for two different fetches. it's always cloned at some point |
| 15:22 | <annevk> | Hmm, I'm not sure that's the right mental model. You need to clone a request if you want to reuse it because we want the developer to be aware of the allocation cost. That's why bodies are consumed and not reusable anyway. |
| 15:27 | <Noam Rosenthal> | Maybe, but it was so far a useful mental model for me to remember how some things work especially around the fetch/sw integration. it's never the same internal request object |
| 16:05 | <Noam Rosenthal> | I have a local PR for equality. I'll post it when the PRs stop failing and my previous PR lands |