| 09:25 | <chargeitall> | does mdn web doc discord channel work on element? |
| 13:37 | <Ms2ger> | annevk: would you take a PR to add <div algorithm> to some or all algorithms in DOM (no promises when I might have time, but the lack of them means that variable highlighting doesn't work) |
| 16:13 | <annevk> | Ms2ger: yes, see Fetch for my preferred style |
| 19:53 | <akaster> | Is it correct to assume that the kind of "requirement on callers" listed here is discouraged for future specs/spec updates? https://html.spec.whatwg.org/multipage/structured-data.html#performing-structured-clones-from-other-specifications > Call sites that are not invoked as a result of author code synchronously calling into a user agent method must take care to properly prepare to run script and prepare to run a callback before invoking StructuredSerialize, StructuredSerializeForStorage, or StructuredSerializeWithTransfer abstract operations, if they are being performed on arbitrary objects. |
| 19:54 | <akaster> | And following that, is there any kind of tracking issue for places that "should be" updated to explicitly manipulate the surrounding agent's execution context stack? |
| 19:57 | <akaster> | As a side note, it seems that Domenic's navigation apis will do that sort of "deferred structured serialize" mentioned in the second example if a navigation history entry needs its history API state serialized/deserialized "in parallel" or on the traversal task source 🤔 |
| 20:01 | <akaster> | Or maybe it was from a webidl callback context in the WaitForAll in navigation history event processing 🤔🤔. I'll have to revive my branch implementing that |
| 20:38 | <akaster> | I think we also ran into this kind of implicit execution context stack issue within the module loading implementation, though that was mostly Andreas this month |
| 20:41 | <TabAtkins> | Hm, why would you think it's discouraged? It's useful to know what implicit assumptions an algorithm makes, when relevant, which might affect how you can/should call it. |
| 20:45 | <akaster> | I would rather see the explicit steps on the actual callers as well, rather than make it implicit |
| 20:46 | <akaster> | When implementing algorithms that call that method, it's hard to keep track of all the context of which algorithms have special requirements |
| 20:49 | <akaster> | In Ladybird at the moment, that manifests as a test failing with an assertion that the execution context stack is not empty, and we then have to go put a RAII helper into the part of the algorithm that needs one. Rather than seeing "prepare to run a script and a callback" as a spec step, we need to hit the code path from the event loop or as a result of the UI process poking the renderer and recognize the source of the assertion failure |
| 23:35 | <Domenic> | Those requirements on callers are not meant to be action at a distance. They're meant to be advice to future spec writers. |
| 23:36 | <Domenic> | Navigation API serialization/deserialization is always on the main thread. |
| 23:39 | <akaster> | Hmm okay, in that case I'll try to document all the "extra" prepare to run script/callback steps we've had to add and see if we're doing something wrong for them or if the steps should be added |
| 23:41 | <akaster> | On the main thread and as a result of a JavaScript call aren't always the same thing though. Maybe we just always need to push a context when interacting from the UI process and it all goes away |