| 00:18 | <TabAtkins> | Huh, yeah, that's confusing. I don't know enough about wattsi to debug that. |
| 00:48 | <Kaiido> | I remember I did test locally when pushing that change and it did work, in fact, running html-build build.sh --remote on my machine today does generate the proper class and renders fine for me. The issue might be in the building-pipes. |
| 01:41 | <Domenic> | Hmmm probably it's because https://github.com/orgs/whatwg/packages?repo_name=html-build doesn't rebuild after Wattsi improvements |
| 01:41 | <Domenic> | I thought we had an open issue on that somewhere |
| 01:42 | <Domenic> | I wish I knew Docker well enough to know how this is supposed to work |
| 01:43 | <Domenic> | Like ideally html-build would have some minimum wattsi version in a file (like Node.js package.json or similar) and we could bump that file and that would force a rebuild. |
| 01:44 | <Domenic> | But right now the html-build -> wattsi dependency is expressed via https://github.com/whatwg/html-build/blob/main/ci-build/Dockerfile#L28 (COPY --from=ghcr.io/whatwg/wattsi:latest) which is good if html-build and Wattsi are both revved frequently but not good in this case. |
| 01:44 | <Domenic> | I believe docker-compose is possibly the relevant tool here but I have not learned it or how to integrate it into our GitHub actions pipeline... |
| 07:58 | <annevk> | Domenic: https://github.com/whatwg/html/pull/10737 strictly speaking doesn't have multi-implementer interest |
| 07:59 | <Domenic> | Oh no :(. When someone tells me "ping, all the boxes are checked" on a PR that's been open for months, I'm inclined to take them at their word :( |
| 07:59 | <Domenic> | I see now that was a mistake |
| 07:59 | <annevk> | I think this is the second time this has happened with Mason. I suggest to no longer do that with him. |
| 07:59 | <Domenic> | Ugh wow that box is definitely checked in error, yeah |
| 08:00 | <Domenic> | Should we revert? |
| 08:00 | <annevk> | I think it's probably okay, unless Mozilla has some objection to it. Need to think about it a bit more. |
| 08:01 | <annevk> | smaug: zcorpan: ^^ |
| 08:29 | <Noam Rosenthal> | One related thing to microtasks/promises... I encountered a few times the issue that if you resolve a promise from platform code, the promise reactions would only run at the end of the task. This is confusing if you have a task that does multiple things that might have reactions or callbacks, like the rendering task. I thought to generalize it where HTML would have its own resolve that resolves the promise inside a "run/cleanup script" scope and specs should be calling that instead of the WebIDL resolve. Wonder what smaug / Domenic think about this |
| 08:30 | <Noam Rosenthal> | Kinda like what I had to do in step #5 of https://html.spec.whatwg.org/multipage/browsing-the-web.html#reveal |
| 08:33 | <annevk> | From the perspective of how they were introduced for mutation observers, it would seem bad if you don't delay them until the end of rendering, as the reactions might incur new things that require rendering. |
| 08:34 | <Noam Rosenthal> | but we already do that when firing events |
| 08:36 | <Noam Rosenthal> | also each rAF callback clears the microtask queue and might incur new things that require rendering etc... |
| 08:36 | <annevk> | Well yes, but that's why we moved from mutation events to mutation observers. So to then suggest that promises should work like events feels a bit backwards. |
| 08:37 | <annevk> | If you don't want promise-timing, don't use a promise. |
| 08:40 | <Noam Rosenthal> | Sometimes promises are there because of ergonomics, not because of anything to do with timing |
| 08:41 | <Noam Rosenthal> | To be clear, I don't think this would change anything existing in the platform. Apart from view transitions, all the other resolve calls are one-per-task |
| 08:41 | <Noam Rosenthal> | (AFAICT) |
| 08:41 | <annevk> | How would it not change the timing of promises already on the queue? |
| 08:44 | <Noam Rosenthal> | There should not be any promises in the queue, only platform microtasks such as mutation observers. But it doesn't matter, because in 100% of uses of resolve today this would be a noop |
| 08:44 | <Noam Rosenthal> | ... because today all the uses of resolve only resolve during the task, so at the end of the resolve you'd get the event loop's microtask checkpoint |
| 08:52 | <annevk> | I don't understand that sentence. You can only call resolve during a task. |
| 08:52 | <Noam Rosenthal> | yes, but no spec does that in practice |
| 08:52 | <annevk> | They do? |
| 08:52 | <Noam Rosenthal> | I mean, no spec calls resolve and then does something else that calls user code in the same task, AFAICT |
| 08:53 | <Noam Rosenthal> | it's usually "queue a task to resolve" |
| 08:53 | <annevk> | I think there's plenty of examples of events or callbacks and promises all being handled in one sweep. |
| 08:53 | <annevk> | As they should. |
| 08:54 | <Noam Rosenthal> | not sure about it, but will go through the specs, maybe my assumption here is wrong |
| 08:55 | <annevk> | There's also plenty of cases where a promise is rejected immediately. Which happens during whatever call did the wrong thing according to IDL. |
| 08:55 | <Noam Rosenthal> | sure |
| 08:56 | <Noam Rosenthal> | ok, perhaps this is not going to work. Thanks for the clarification |
| 09:13 | <Domenic> | The cases I am concerned about which are adjacent to (or the same as?) the ones Noam Rosenthal is discussing are the ones where promises and event firing are next to each other, and thus the existence of event handlers can change the ordering. See https://html.spec.whatwg.org/#note-suppress-microtasks-during-navigation-events . In such cases we can manually add something to the stack to prevent promises from immediately resolving when the events are fired. That seems OK as it makes the promises more delayed. It's only happened a couple of times so far so we haven't needed to do it more generally. |
| 09:14 | <Domenic> | I think Noam's case is basically the same as mine. |
| 09:15 | <Domenic> | I don't really know how to generalize it though; just wrapping the resolve in run/cleanup a script wouldn't work. You need wrap both the "fire an event" and the "resolve". |
| 09:21 | <Noam Rosenthal> | Yea these timing gotchas are not trivial at all to an outside spec to deal with. But not sure what the right solution is |
| 09:55 | <annevk> | Domenic: can't you fire the event and then resolve? |
| 13:21 | <keithamus> | Given both WebKit and Mozilla track standards positions in public GitHub issues, do you think it is worth adding some tooling to PRs to scrape the API and check that A) an issue is supplied linking to the standards position of those respective vendors and B) that issue has the correct label on it, marking the vendor as supportive? |
| 13:22 | <keithamus> | It could be a CI check that fails a PR unless it is able to successfully confirm that each vendor is indeed supportive, reducing the human error involved. |
| 13:26 | <Luke Warlow> | It could be a CI check that fails a PR unless it is able to successfully confirm that each vendor is indeed supportive, reducing the human error involved. |
| 13:28 | <keithamus> | I imagine the option to skip those checks could be added via a checkbox saying "standards positions aren't necessary for this", which would pass the check but could provide a signal to the editors merging that this hasn't gone through standards positions |
| 14:50 | <annevk> | keithamus: I wouldn't be opposed to that being available, but as I clarified at some point WHATWG uses "implementer interest" which is quite informal (though you do need to actually have someone say it). Going through standards-positions to obtain that is fine, but it's not required. |
| 14:51 | <keithamus> | that makes sense. Perhaps it would be too much then. |
| 16:13 | <Luke Warlow> | Is there any documentation or issues to read about how moveBefore interacts with stuff like mutation observer? |
| 16:25 | <annevk> | https://github.com/whatwg/html/pull/10904/files moves a bunch of text and then makes some tweaks. Is there a good way to highlight the changes? I guess copy-and-paste it all and do a manual diff? |
| 16:56 | <Andreu Botella> | Hey, both I and nicolo-ribaudo wanted to join today's WHATNOT meeting to talk about the web integration AsyncContext, and we don't have an invite |
| 17:02 | <nicolo-ribaudo> | Figured it out |
| 18:01 | <annevk> | Andreu Botella: is there a comment/document somewhere explaining this new design and in particular why it was changed? |
| 18:03 | <smaug> | Andreu Botella: FWIW, I'm still super worried about any implicit context capture (assuming I understand the proposal correctly). That kind of things tend to cause leaks. |
| 18:03 | <Andreu Botella> | Andreu Botella: is there a comment/document somewhere explaining this new design and in particular why it was changed? |
| 18:04 | <Andreu Botella> | Andreu Botella: FWIW, I'm still super worried about any implicit context capture (assuming I understand the proposal correctly). That kind of things tend to cause leaks. awaits and .then |
| 18:05 | <smaug> | So how would DOM callbacks deal with this then? I'm a bit confused. The proposal talks about "associating state implicitly " |
| 18:06 | <Andreu Botella> | I think this is clearer in https://github.com/tc39/proposal-async-context/pull/109 |
| 18:07 | <Andreu Botella> | For things like setTimeout, you'd store the context with the callback, and get rid of it afterwards (or for setInterval, when it gets canceled) |
| 18:07 | <smaug> | Ok, so context is stored implicitly with the callback? |
| 18:09 | <Andreu Botella> | Ok, so context is stored implicitly with the callback? |
| 18:09 | <Andreu Botella> | event listeners would not store the context |
| 18:09 | <annevk> | Andreu Botella: for a change of this magnitude I'd expect a bit more. I mean I gave feedback too, but that apparently has been dismissed now. |
| 18:09 | <nicolo-ribaudo> | The difference is that now we capture implicitly for callbacks that are going to be run (unless explicitly cancelled) and not for things that _may run_ like event listeners (where you don't know if it's ever going to be triggered again, so you can't ever free the context) |
| 18:20 | <Andreu Botella> | To avoid misunderstandings: this proposal talks about propagating the context implicitly, as a way to frame the expected behavior for context passing. This could be implemented by changing the way task queueing and "in parallel" work in engines, but for the initial rollout we propose only exposing things that could be implemented in other ways. |
| 18:21 | <Andreu Botella> | You could implement/spec setTimeout as implicitly passing the context to the "in parallel" code, and then implicitly passing that same context to the queued event loop task |
| 18:21 | <Andreu Botella> | Or you could store the context with the callback |
| 18:22 | <Andreu Botella> | I don't think this is a change from what we discussed in TPAC |
| 18:26 | <annevk> | I'm not sure I was at the discussion at TPAC, but I'm pretty sure I gave feedback that per-thing handling feels extremely error prone. |
| 18:27 | <annevk> | Especially for events. |
| 18:33 | <Andreu Botella> | I'm not sure I was at the discussion at TPAC, but I'm pretty sure I gave feedback that per-thing handling feels extremely error prone. |
| 18:34 | <Andreu Botella> | but for the initial rollout, there would be a very small list of events that would be special-cased so the context does propagate for those |
| 18:34 | <Andreu Botella> | because that can be implemented without the implicit tracking |
| 19:34 | <smaug> | Andreu Botella: It is quite confusing to have some callbacks work in certain way and other in some other way. And for example idle callbacks aren't guaranteed to be run, even though the are "scheduled". Nothing ensures there is idle time ever. |
| 19:36 | <smaug> | (I'm just super concerned about memory leaks here, just given, as an example, the massive leaks Youtube fixed couple of days ago. At least some of them were exactly about capturing certain things semi accidentally and keeping them alive for too long) |
| 19:40 | <Andreu Botella> | Andreu Botella: It is quite confusing to have some callbacks work in certain way and other in some other way. And for example idle callbacks aren't guaranteed to be run, even though the are "scheduled". Nothing ensures there is idle time ever. |
| 19:41 | <Andreu Botella> | Well, "the same as implicit propagation" isn't strictly true, because multiple rAF callbacks can be scheduled on the same event loop iteration (or the same task in some implementations), but you'd still want each to propagate its own context |
| 19:42 | <Andreu Botella> | but it's a similar concept |
| 23:49 | <Domenic> | This discussion of "for the initial rollout" seems scary; I cannot imagine changing this sort of thing after it's shipped. |
| 23:50 | <Domenic> | I would prefer the final semantics are worked out ahead of time, as part of the "initial rollout". |