| 12:26 | smaug | cries a little bit. Yet another "let's break how microtasks work" special case. (but maybe he did review that change? Hard to get back to the spec issue from the commit message) |
| 12:30 | <Noam Rosenthal> | This was me and it was thoroughly reviewed. |
| 12:31 | <Ms2ger> | https://github.com/whatwg/html/pull/10284 |
| 12:32 | <Noam Rosenthal> | Yea I think we had the discussion about this with Domenic elsewhere... |
| 12:33 | <smaug> | Looks like google only patch and review |
| 12:33 | <Noam Rosenthal> | the problem with microtasks in the rendering loop is that they might be postponed until the end of the rendering task and that's a no-man's land |
| 12:33 | <smaug> | Oh, I do understand how microtasks work and what their limitations are 😛 |
| 12:34 | <smaug> | but it is getting really hard to explain how microtasks work given the special cases. Navigation API has similar weird special case |
| 12:34 | <Noam Rosenthal> | yea agreed, there are a few of those |
| 12:35 | <Noam Rosenthal> | but really I think those special cases can be counted on one hand |
| 12:36 | <sideshowbarker> | so we have enough to start a Quirks spec for microtasks |
| 12:36 | <Noam Rosenthal> | I suggested before to have something like an isolated promise resolver algorithm that does this... it's probably easier to explain then wrapping each of these separately |
| 12:36 | <Ms2ger> | Does it need to be an AI-generated hand? 😇 |
| 12:40 | <Noam Rosenthal> | The quirky things about microtasks is when they need to fire before other things in the same task... then you need to wrap them with this prepare/cleanup thingy. I think the right way to explain it is to have some sort of isolated wrapper for this but it wouldn't look much different from those prepare/cleanup pairs |
| 12:41 | <Noam Rosenthal> | (though so far this sounds like more like a group rant than an attempt to fix things, so perhaps I'd leave it to that) |
| 12:46 | <smaug> | I guess we'd need conceptual MilliTasks, and Microtasks would run then at the end of outermost script execution or end of millitask or task. |
| 12:46 | <Noam Rosenthal> | we kind of have that. you can call script execution blocks millitasks |
| 12:46 | <Noam Rosenthal> | (I wouldn't use the term, but the concept exist) |
| 12:49 | <Noam Rosenthal> | but really what I found myself looking for a few times is more like "when you resolve this promise, if there is no active script, also perform a microtask checkpoint and flush the world". the default behavior of delaying that to the end of the task is what's quirky |
| 12:50 | <smaug> | yeah, that largely comes from the fact that microtasks weren't designed for promises |
| 12:50 | <Noam Rosenthal> | (end of the task or an event handler or callback that might happen to run) |
| 12:51 | <Noam Rosenthal> | sure, but that's why a wrapper to "resolve a promise" or to wrap a prepare/cleanup pair for promise resolution and expose that in an algo is not a bad solution |
| 12:53 | <smaug> | it makes explaining microtasks hard. "usually microtasks run at this time, but then we have these special cases" |
| 12:53 | <Noam Rosenthal> | they run when the JS stack is emptied from running scripts or at the end of the task. We can say that these promise-based entry points create a JS Stack |
| 12:55 | <Noam Rosenthal> | it's not a "special case" per se, it creates JS stacks/scopes whatever when there is a promise-based API callback |
| 13:19 | <Noam Rosenthal> | The alternative way to explain this is by having these sub-tasks be tasks and manage the order via task queues... I'm pretty sure that would be more cumbersome and won't solve anything. |