| 04:53 | <Noam Rosenthal> | Hi zcorpan and @etportis! Are you actively working on finishing https://github.com/whatwg/html/pull/5574? need any help? |
| 04:53 | <Noam Rosenthal> | Eric Portis (he/him): ^^ |
| 07:14 | <annevk> | Eric Portis (he/him): if you grab a handle to iframe.contentWindow and then do iframe.remove(); you'll have a window without viewport (or browsing context) |
| 08:25 | <Piers Wombwell> | I did a PR for the HTMLAllDocument tweak, but it's stuck saying I've not signed the participation agreement. My org's in the entities.json file, but unverified as I've not contributed. Is that why the PR's stuck or have I done something wrong? https://github.com/whatwg/html/pull/6802 |
| 08:30 | <Ms2ger> | Probably someone needs to push a button somewhere |
| 08:30 | <Ms2ger> | Maybe annevk ? |
| 08:31 | <sideshowbarker> | yeah there’s a manual verification step each time that basically doesn’t happen until the contributor submits their first PR |
| 08:32 | <sideshowbarker> | so this all normal and expected, I think |
| 08:32 | <annevk> | Yeah, when someone gets around to reviewing your first PR they'll take care of that Piers Wombwell |
| 08:33 | <annevk> | No button unfortunately, we edit JSON directly on main 😊 |
| 08:47 | <Piers Wombwell> | Sorry, got interrupted by a plumber. That makes sense. foolip wrote a wpt that covers most of the 'all-named' elements. Not sure what's best, whether to extend that test or write a new one. Whatever, it'll pass in all browsers as the existing live-dom-viewer test page demonstrates. |
| 08:48 | <foolip> | Is document.all still not done? I thought I was comprehensive last time :) |
| 08:51 | <Piers Wombwell> | It's a very helpful test case - saved me loads of time when implementing document.all. But it doesn't cover every named element. |
| 08:51 | <Piers Wombwell> | It does the hard job of testing lots of attribute values. |
| 08:52 | <Piers Wombwell> | Separately I noticed there's a RtoL control code in the source file immediately before 'Pooja Sanklecha' in the acks list. It doesn't seem to be necessary as the name always renders LtoR. |
| 09:17 | <Ms2ger> | tabatkins: any news on https://github.com/tabatkins/bikeshed/issues/1667 ? I just wanted to file it again |
| 10:58 | <zcorpan> | Noam Rosenthal: I'm not working on it now |
| 16:14 | <jgraham> | Do we already have the concept of an event loop for the "parent process" (i.e. one that operates indpendently of a specific ES global)? |
| 16:20 | <annevk> | jgraham: "in parallel" |
| 16:21 | <annevk> | (i.e., "no") |
| 16:21 | <Domenic> | Well, and you can use parallel queues if you want to sequence something ther |
| 16:26 | <jgraham> | Right, so currently WebDriver-BiDi is using "in parallel" to defer some things, but it feels like it would be much easier if we could just reuse the task queue stuff (especially because there's a "wait for one of the following events to happen", which implementation wise is almost certainly Promise.race or C++ equivalent). So I was thinking of defining/handwaving a "user-agent event loop" which could then allow reusing the task scheduling. |
| 16:27 | <jgraham> | Obviously for Gecko in particular where we have js in the parent process, this is exactly how things actually work, although other implementations are different. |
| 16:28 | <Andreu Botella (he/they)> | A parallel queue seems close enough |
| 16:35 | <jgraham> | Yeah, I guess I could just use parallel queues directly, unless we care about the distinction between tasks and microtasks. It might be sufficiently unobservable that it doesn't matter, but in practice I"m fairly sure the implementations will actually use promises and therefore microtasks. |
| 16:35 | <Domenic> | I would be surprised if Chromium was going to use promises (and thus V8) in the browser process... |
| 16:36 | <annevk> | Also, if it's cross-process you have to queue a task anyway to resolve the promise from, at which point there's no distinction |
| 16:41 | <jgraham> | Yeah, I'm not claiming that Chrome is going to use V8 in the browser process. I assume you have a similar construct on the C++ side, but maybe not (also I'm not sure how much of Chrome's implementation is going to be novel vs reusing existing devtools events and whether that makes a difference; there is a prototype that works under node as a CDP client, and one can imagine building something similar inside Blink, but I don't think that's the final implementation strategy). |
| 16:42 | <jgraham> | Anyway, if the general consensus is that I should use a parallel queue as an event loop then I guess I'll do that. |
| 16:44 | <jgraham> | (I guess the whole parallel queue thing is theoretically problematic because it doesn't guarantee scheduling between different queues but in practice I don't think implementations are going to have one thread per queue so actually only one ordering is possible, and something could depend on that unspecified ordering) |
| 16:45 | <wanderview> | chromium does not really have c++ promises like gecko does |
| 17:23 | <Domenic> | annevk: can I get a rubber-stamp review (or in-depth review) for https://github.com/web-platform-tests/wpt/pull/28480 ? Nate did a review but doesn't have reviewer permissions |
| 17:50 | <annevk> | Nate should probably ask for access in #wpt:matrix.org |
| 18:46 | <Domenic> | Ah, that's where that room went... there's no pointer in the WPT docs or the IRC channel. |
| 19:54 | <foolip> | Domenic: https://github.com/web-platform-tests/wpt/pull/29484 |
| 23:53 | <timothygu> | Piers Wombwell: if you're implementing document.all, beware of https://github.com/whatwg/html/issues/4098. It's the last remaining deviation of existing browsers from the spec (though thankfully current browsers seem to all do the same thing) |