| 04:57 | <akaster> | referencing <https://github.com/whatwg/html/issues/9920>; is it the case that all 3 major engines use separate processes for Shared/ServiceWorkers but keep DedicatedWorkers in the same process as the renderer, just in different threads? |
| 04:59 | <akaster> | I was hoping to start implementing DedicatedWorkers in Ladybird assuming that any worker type would "always" have its own process (until there's too many processes and we have to start sharing etc etc). Which would mean we can keep covering our ears and pretend that the thread-unsafety of LibWeb/LibJS can wait until 'later' still. |
| 05:01 | <akaster> | Per the issue, Domenic: was saying his understanding was that that's not a good idea because of the requirements for SharedArrayBuffers in the ECMAScript spec. |
| 05:03 | <Domenic> | referencing <https://github.com/whatwg/html/issues/9920>; is it the case that all 3 major engines use separate processes for Shared/ServiceWorkers but keep DedicatedWorkers in the same process as the renderer, just in different threads? |
| 05:06 | <akaster> | Hmm all right.. well, we'll have to handle distinct realms existing in the same process to handle window.open, so handling separate agents (called VM, in our implementation) is probably not going to be too far from that. I'm mostly worried about the places where we still reach out to the "main thread VM" Singleton.. would be nice to always know which agent we're working with though. |
| 05:54 | <Domenic> | same-origin window.open, but also same-origin iframes |
| 06:41 | <Jake Archibald> | HTML property setters seem inconsistent when it comes to throwing or silently ignoring invalid values. Is either of those seen as the "right way" these days? |
| 07:35 | <annevk> | Jake Archibald: methods generally throw, setters generally ignore (and then the getter continues to return the same value); this is somewhat enforced for enums |
| 07:39 | <annevk> | I guided someone to follow the "new feature" template a bit more closely and https://github.com/whatwg/dom/issues/1233 is quite understandable now in terms of what it's trying to achieve. Hopefully it continues to work that well. |
| 07:45 | <Jake Archibald> | Jake Archibald: methods generally throw, setters generally ignore (and then the getter continues to return the same value); this is somewhat enforced for enums valueAsDate throwing on, say, a range input, is that breaking convention, or is it correct by some other rule? |
| 07:46 | <Jake Archibald> | https://html.spec.whatwg.org/multipage/input.html#dom-input-valueasdate |
| 07:50 | <annevk> | Jake Archibald: I think valueAsDate is breaking several conventions; doesn't it return a new object each time you invoke the getter? |
| 07:51 | <Jake Archibald> | Ohh that's a good point |
| 07:51 | <annevk> | Jake Archibald: having said that, I guess I'm not entirely sure about what the convention is for non-enums, but I wouldn't base precedent on valueAsDate. |
| 08:19 | <Domenic> | I'm not sure setters ignoring is really best practice, but I admit not thinking too hard about it... |
| 08:19 | <Domenic> | In JS itself there are some cases where setters throw in strict mode and ignore in sloppy mode, IIRC. |
| 08:51 | <chargeitall> | Is this anchor meant to serve as a placeholder to describe the grammar and lexical scanner? https://www.w3.org/TR/css-syntax-3/#placement |
| 10:13 | <annevk> | Domenic: https://github.com/WICG/observable/issues/71#issuecomment-1804956795 say we had this "new thing", couldn't you refactor EventListener in terms of that? |
| 10:14 | <Domenic> | Domenic: https://github.com/WICG/observable/issues/71#issuecomment-1804956795 say we had this "new thing", couldn't you refactor |
| 10:15 | <annevk> | Domenic: well that could also be the overload, provided Web IDL gets support for that |
| 10:16 | <annevk> | Domenic: but thanks, that confirms my suspicion that these patterns are in fact identical |
| 10:17 | <Domenic> | It's a bit tricky because it seems like the use cases are:
|
| 10:18 | <Domenic> | Unifying streams & EventListener & observable-maybe seems doable, with minor tradeoffs in syntax that make one case nicer than others. |
| 10:19 | <Domenic> | Custom elements is probably too wacky, although you might want to design both at once and share as much infrastructure & syntax as possible. |
| 10:19 | <Domenic> | Oh right, what do worklets need... I think they're the same as custom elements? |
| 10:21 | <Domenic> | Yes, or at least PaintWorklet is |
| 10:23 | <annevk> | Does kind of have strong "callback interface" vibes |
| 10:25 | <Domenic> | I dunno, I think you're forgetting how weird and Java-ey callback interfaces were. E.g. the constants, the legacy callback interface object stuff. They definitely didn't have dictionary-type semantics for properties, which is what we'd want here. |
| 10:25 | <Domenic> | I guess I would say "callback dictionary" is what we want, vs. "callback interface" |
| 10:26 | <annevk> | True, NodeFilter still exists btw |
| 10:44 | <annevk> | akaster: using a process as agent boundary seems interesting, but also quite bad for perf? The idea is that a document and its dedicated workers end up in a single agent cluster. Which can be 1:1 with a process, but even that you might not want to do as you'd get many processes that way too. Existing user agents typically share multiple agent clusters in a single process. |
| 10:45 | <annevk> | akaster: also note that you can have multiple realms/globals within a single agent with <iframe> too, not just window.open(). |
| 17:07 | <akaster> | I think there's many lower hanging fruit for perf than process boundaries in our implementation at the moment. I think the isolation possibilities are a lot more interesting as well. And we don't even support SharedArrayBuffers yet š . From my reading of the JS spec it seems like there's no reason we *couldn't* do it that way, but perhaps some of the total ordering constraints will force us to put all the agents in an agent cluster in one memory space in the future |
| 19:14 | <Dominic Farolino> | Dependent/source abort signals are a little confusing to me. https://dom.spec.whatwg.org/#create-a-dependent-abort-signal step 4.2.1 seems to assert that a source signal is itself not dependent. Does this mean that there can not be a chain of dependent signals more than 3 long? |
| 21:39 | <TabAtkins> | Is this anchor meant to serve as a placeholder to describe the grammar and lexical scanner? https://www.w3.org/TR/css-syntax-3/#placement |
| 23:01 | <sideshowbarker> | TabAtkins: About the test at https://wpt.fyi/results/css/css-animations/animation-canceled-by-parent-details-element-being-closed.html, I havenāt managed to to figure out what that test should rightly be checking ā rather than checking for a In Chrome that test fails, because when a But looking at https://drafts.csswg.org/css-animations/ and at https://drafts.csswg.org/css-contain-2/#:~:text=While%20an%20element%20is%20skipped%2C%20CSS%20transitions%20and%20animations%20on%20the%20element%20do%20not%20update, I anyway can find neither any spec support for firing a Iād like to fix the test, but at this point, I have no idea what to make it check for. |
| 23:12 | <TabAtkins> | sideshowbarker: Oh sorry, I know you posted this earlier but I didn't get to it immediately and then immediately forgot about it. |
| 23:13 | <TabAtkins> | So the test previously was assuming that the contents of details was display:none when it closed, which does indeed cancel animations |
| 23:13 | <sideshowbarker> | No worries |
| 23:14 | <TabAtkins> | but yeah, assuming details are now specified to use content-visiblity, the animation won't be canceled, it'll just stop updating until it's relevant again |
| 23:18 | <sideshowbarker> | OK ā I guess thereās no way to check for the the animation is in the āhas stopped updatingā state? |
| 23:19 | <TabAtkins> | Correct. But you could ensure that the animation should run for a decent amount of time, and then verify you didn't get a cancel shortly after closing the details (implying that it's still active in some state) |
| 23:20 | <sideshowbarker> | OK |