| 07:29 | <annevk> | littledan: so this nested event loop investigation I’m doing might influence the way we split the runtime between ES and hosts a bit |
| 07:30 | <annevk> | littledan: at least some UAs have the ability to pause a job, execute the remaining ones, and then execute the remainder of the paused job (simplified) |
| 07:32 | <littledan> | Annevk, yeah, I have been watching this thread with some interest. Do you have a test case? |
| 07:33 | <littledan> | This can happen while processing multiple mutationobserver callbacks? |
| 07:33 | <annevk> | littledan: any microtask really, no test yet |
| 07:34 | <annevk> | littledan: I guess another way of putting it is that some privileged callers have direct access to the queue |
| 07:35 | <littledan> | Well, for the potential layering change, I would imagine that, at most, the microtask queue is in JS, and the rest of the event loop remains in HTML |
| 07:36 | <littledan> | So, it would help to understand how the access is privileged with respect to the microtask queue specifically |
| 07:37 | <littledan> | I saw wording about the incumbent settings object as well |
| 07:38 | <annevk> | And active document iirc |
| 07:39 | <littledan> | Annevk: well, thanks for the investigation and summary, this is helpful for my presentation to TC39 to codify HTML's role in the willful violation layering |
| 07:39 | <littledan> | Which has confused folks in the past |
| 08:27 | <annevk> | littledan: I think part of that was being able to land text in the JS spec without much review |
| 08:28 | <annevk> | littledan: from the beginning Hixie asked for a diff archirecture and pointed out issues with what was put in |
| 10:02 | <littledan> | Well, I am not a big fan of the JS spec's current text at all. I would imagine something much simpler, without using the word implementation-defined, and without trying to outline how the event loop works |
| 10:02 | <littledan> | (that is, if we want to go with something other than the current HTML text, and I am happy with the current text) |
| 10:04 | <littledan> | annevk: in a recent call with some framework authors, we got a lot of interest in discussing HTML topics. See https://docs.google.com/document/d/1vvL357Z6r9IYTItvNwBf0wRH-uT4J_bAFIqnbQb-13I and grep for HTML to see the list |
| 10:04 | <littledan> | I'd welcome WHATWG folks to the next call to discuss these topics |
| 10:04 | <littledan> | Several DOM things too |
| 10:04 | <littledan> | Let me know if you want me to send an invite |
| 10:06 | <annevk> | littledan: please do |
| 14:57 | <annevk> | Domenic: https://github.com/web-platform-tests/wpt/pull/15769 should be good now btw |
| 15:19 | <Domenic> | annevk: I want to pull down locally and debug in Chrome; those errors are still very surprising. |
| 15:22 | <annevk> | Domenic: presumably that shouldn't affect the test though given results in Firefox and Safari? |
| 15:23 | <annevk> | anyway, seems fine I guess |
| 15:27 | <Domenic> | My suspicion is another Chrome bug/interop problem with e.g. onload is preventing the test from actually testing named property behavior. |
| 15:29 | <annevk> | Speaking of which, it'd be really nice if we got toward a world with consistent load events |
| 16:04 | <Domenic> | Yes... it is surprising that we mostly run into this in tests, instead of web developers running into it all the time and being mad. |
| 18:15 | <jyasskin> | lgrahl/annevk: I can confirm that I wasn't thinking about the permission store itself being behind an IPC when I wrote https://www.w3.org/TR/permissions/#reading-current-states. It's possible it needs a note like in https://www.w3.org/TR/permissions/#requesting-more-permission warning spec authors to only call it in parallel. I *think* that all the uses already obey that, but I haven't checked them all. |
| 18:16 | <annevk> | jyasskin: that doesn't work though, there's no settings objects there |
| 18:22 | <jyasskin> | annevk: Hmm. https://www.w3.org/TR/permissions/#requesting-more-permission has that problem too, and talks about the "current realm", which also isn't accessible from "in parallel". We only use the settings object to call https://w3c.github.io/webappsec-secure-contexts/#is-settings-object-contextually-secure, which I think relies only on immutable bits of the settings object? So, is there actually a race condition here, or |
| 18:22 | <jyasskin> | just some need to make the immutable parts of a settings object available from asynchronous contexts? |
| 18:23 | <annevk> | jyasskin: what if the settings object has gone away? |
| 18:23 | <annevk> | jyasskin: "current" definitely doesn't work so you'd require to pass it in |
| 18:24 | <annevk> | jyasskin: but it seems safer to require someone passing the bits in they need |
| 18:24 | <annevk> | jyasskin: and it seems safer still to provide some kind of "in parallel" wrapper for specs to use |
| 18:25 | <annevk> | That was a bit unclear, require passing the bits of a settings object that your algorithm needs |
| 18:25 | <jyasskin> | Is https://html.spec.whatwg.org/multipage/webappapis.html#event-loop-for-spec-authors the only place we actually say that you can't use settings objects from "in parallel"? |
| 18:25 | <annevk> | And then abstract from there to make it still reasonable to call |
| 18:26 | <annevk> | jyasskin: could be, we have very little documentation around "in parallel" and as we discussed in the past "in parallel" isn't the greatest |
| 18:29 | <jyasskin> | (Noting that I don't really mind having the permissions algorithms taking the few bits of a settings object that they actually need explicitly...) There's a natural meaning for the "current realm" in a parallel context: it's just the current realm of whatever step fired off the parallel task. I'd want to handle tasks that are running after the settings object has "gone away" in the same way we handle anything else using |
| 18:29 | <jyasskin> | something that has gone away: the garbage collector must not create that situation. |
| 18:32 | <annevk> | jyasskin: that's an interesting argument |
| 18:33 | <annevk> | jyasskin: it's also a fair amount of magic that I'm hoping won't backfire in some way |
| 18:34 | <annevk> | jyasskin: with event loops we're fairly conservative as to what can cross the boundary (tasks) |
| 18:36 | <jyasskin> | We do have problems around users closing windows, which should neuter some objects, and I don't think we have the terminology we need to talk about that well. But document objects already survive past that user action. |
| 18:38 | <jyasskin> | I think "queue a task" has some of its own problems if settings objects die in the middle of parallel steps. Where the task gets queued and the "current realm" of that task is totally implicit. |
| 18:39 | <jyasskin> | I should get a *really good* intern to spend a summer figuring all of this out. |
| 19:18 | <annevk> | Isn’t it up to senior folks to sort tech debt so interns can do something new or some such? |
| 20:01 | <jyasskin> | annevk: That would be awesome. |