| 09:04 | <annevk> | littledan: let me know at what point https://github.com/whatwg/html/pull/4372 is ready for nits |
| 09:05 | <annevk> | littledan: and thanks for writing it up! |
| 09:14 | <annevk> | TimothyGu: I'll leave https://github.com/whatwg/html/pull/4368 open until you can verify my analysis, but I think it's good still |
| 09:16 | <littledan> | Annevk, never too early for a review, but it will be some months or maybe a year. I will note in the PR thread when ready. |
| 09:17 | <littledan> | How would folks feel if I proposed some of the HTML job queue to be part of JS semantics? No normative changes, but maybe this could clear up the willful violation in this area. |
| 09:17 | <littledan> | Domenic: ^ |
| 09:17 | <littledan> | This willful violation is causing extra complexity for several JS specs |
| 09:19 | <annevk> | littledan: so the last time we looked into this the simplest setup would be for JS to queue (perhaps annotated) things and let the host take care of organizing where to put those |
| 09:19 | <annevk> | littledan: I suppose we could move more of HTML into ES, but that seems really tricky to get right |
| 09:19 | <littledan> | I see. Where does the complexity come in? |
| 09:20 | <littledan> | (oh sorry rereading your above question, the PR is already ready for nits) |
| 09:21 | <annevk> | littledan: I mean, HTML's event loop algorithm is not simple |
| 09:21 | <littledan> | In particular, there was interest in TC39 in standardizing microtask queue semantics across JS environments to make things more predictable, which seems like a nice goal to me |
| 09:21 | <littledan> | The event loop would be in HTML still... OK, sounds like I should read more details and I will probably see where it doesn't work for myself |
| 09:21 | <annevk> | littledan: and afaik ES only queues what HTML calls microtasks and those only happen in special places and even those also have their own HTML-specific logic surrounding them |
| 09:22 | <littledan> | What's HTML -specific about that logic? |
| 09:22 | <annevk> | littledan: https://html.spec.whatwg.org/#perform-a-microtask-checkpoint |
| 09:23 | <littledan> | Oh, that's the thing, I think we will need to perform microtask checkpoints from the JS spec |
| 09:23 | <annevk> | littledan: promise rejection notification, database cleanup, the manipulation of the event loop (I'm not sure what that does) |
| 09:24 | <littledan> | Well, at least Step 2 |
| 09:24 | <littledan> | Of that algorithm |
| 09:24 | <annevk> | littledan: interesting |
| 09:24 | <littledan> | Maybe we should just make a host hook for microtask checkpoints |
| 09:26 | <annevk> | "just" 😃 |
| 09:26 | <littledan> | But, I think we might need to at least run through the microtask queue between sibling modules as part of the top-level await proposal |
| 09:26 | <littledan> | I will have to think more about whether the other parts are required |
| 09:27 | <annevk> | I think it would help a lot to look at existing software architectures here and base the standard on those |
| 09:27 | <littledan> | What's an example? |
| 09:28 | <annevk> | E.g., SpiderMonkey <> Gecko |
| 09:28 | <annevk> | Or V8 <> Chromium |
| 09:28 | <annevk> | Or V8 <> Node |
| 09:28 | <littledan> | Oh, for the layering? |
| 09:28 | <annevk> | Yeah |
| 09:28 | <littledan> | We are already well past that! JS engines include lots of things from HTML and WebIDL |
| 09:28 | <annevk> | ES could still impose restrictions on hosts to make them consistent somehow |
| 09:29 | <littledan> | Well, lots is an exaggeration |
| 09:29 | <annevk> | And for some of those things it would indeed make sense to define them in ES, as we previously discussed 😃 |
| 09:29 | <annevk> | I'm pretty sure the event loop is not in V8 or SpiderMonkey though |
| 09:30 | <littledan> | But, at the same time, V8 includes (or at one point included) step 2 of the perform a microtask checkpoint algorithm (which is what I think I need) |
| 09:30 | <littledan> | V8 definitely doesn't include the broader event loop |
| 09:31 | <annevk> | So step 2 is basically an agent having a microtask queue and some abstract operation iterating over it and draining it? |
| 09:31 | <annevk> | Well, except for "Set the event loop's currently running task to oldestMicrotask." |
| 09:31 | <littledan> | Right... I will have to look into how the currently running task is maintained |
| 09:35 | <annevk> | Seems to be mostly for compound microtasks, i.e., mutation observers, but Domenic investigated all this last |
| 09:42 | <littledan> | Thanks for the pointer; that is an area I don't understand as well |
| 09:47 | <annevk> | Looking at https://dom.spec.whatwg.org/#notify-mutation-observers I guess there's a bug there in that the slotchange event also needs to be dispatched from a compound microtask subtask... |
| 09:49 | <annevk> | Hmm, how does that work at all, since an event can result in multiple callbacks... |
| 09:49 | <annevk> | Time to file an issue I guess |
| 09:53 | <annevk> | https://github.com/whatwg/dom/issues/734 for those curious |
| 10:04 | <MikeSmith> | annevk: about https://github.com/whatwg/fetch/issues/871 it seems somebody should have thought to take time to confirm with you first |
| 10:05 | <MikeSmith> | I mean about https://bugzilla.mozilla.org/show_bug.cgi?id=1508661 |
| 10:05 | <MikeSmith> | at least Cc you |
| 10:06 | <annevk> | MikeSmith: I dunno, given that Chrome and Safari were already passing those tests there was really no indication (other than misreading of the spec text) that suggested that needed to be done |
| 10:07 | <annevk> | MikeSmith: I suspect I made a mistake by assuming fetch()'s default was "no-cors" or some such |
| 10:07 | <annevk> | MikeSmith: I'm somewhat surprised it took until Firefox changed for this to be found out however, that makes little sense |
| 10:07 | <MikeSmith> | yeah |
| 10:12 | <MikeSmith> | I also don’t understand how, given the browsers passing those tests, server systems could work as expected if they rely on taking the value of the Origin header and using it to set the value of the Access-Control-Allow-Origin header |
| 10:12 | <MikeSmith> | there must be a lot of servers and server CORS libraries which do that |
| 10:12 | <annevk> | MikeSmith: yeah that doesn't make any sense, maybe nobody is using fetch() |
| 10:13 | <MikeSmith> | I think Adam Rice said at the TAG f2f that Chrome use counters show usage of fetch() is around 9% of pages |
| 10:15 | <annevk> | MikeSmith: maybe it's only same-origin |
| 10:16 | <MikeSmith> | ah yeah maybe so |
| 10:18 | <MikeSmith> | annevk: yeah another data point is that I’ve never seen and question posted to Stack Overflow from somebody indicating that their browser wasn’t sending the Origin header for GET requests |
| 10:18 | <MikeSmith> | (and I pretty much read every single CORS-tagged question posted to SO, for the last 2 years or so) |
| 10:19 | <annevk> | MikeSmith: so also, if it's just same-origin the specification wasn't misread, because the CORS flag is only set once cross-origin |
| 10:19 | <annevk> | MikeSmith: so maybe the spec has a bug here after all |
| 10:19 | <annevk> | MikeSmith: I guess I need to do some more digging |
| 10:20 | <annevk> | but maybe not today |