| 14:00 | <nox> | Is UIEvent supposed to be exposed only on Window? |
| 14:14 | <annevk> | nox: seems logical |
| 21:10 | <smaug> | esprehn: you might recall why HTML spec has compound microtasks? |
| 21:12 | <esprehn> | I'm not familiar with that term |
| 21:13 | <smaug> | ah. I'm mostly wondering why MutationObservers and others (well, Promises) get processed differently |
| 21:14 | <smaug> | feels like a bug to me, but I'm clearly missing something, since I don't know why we have these special cases |
| 21:17 | <esprehn> | smaug: the spec doesn't define the term, this whole section probably needs some love |
| 21:17 | <esprehn> | it looks like compound microtask are related to spinning nested event loops if im reading this right |
| 21:17 | <smaug> | well, https://dom.spec.whatwg.org/#queue-a-mutation-observer-compound-microtask |
| 21:18 | <smaug> | and then HTML spec uses that |
| 21:18 | <smaug> | but I don't understand why MutationObservers are special here |
| 21:19 | <esprehn> | hmm that looks like batching ? |
| 21:19 | <esprehn> | the spec needs to define what a compound vs ... microtask is and what they're for |
| 21:23 | <smaug> | Why each MO couldn't be notified as a normal microtask? |
| 21:23 | <esprehn> | smaug: or not. this actually seems like it's trying to describe the behavior where mutations inside microtasks queue more MutationObserver deliveries |
| 21:24 | <esprehn> | that's a good question. I dont think we have any of this special handling in the engine. I'm curious what the spec is trying to do here. |
| 21:26 | <smaug> | esprehn: ok. thanks. I'll try hunt the source for this particular spec text tomorrow. |
| 21:26 | <esprehn> | our system is based on a scope with a depth counter. when the scope is exited and the depth is zero run microtasks. anything that would queue a microtask while in the process of delivering microtasks prolongs that delivery step. |
| 21:26 | <smaug> | maybe Domenic remembers |
| 21:27 | <smaug> | in Gecko MT (MutationObserver one, not the buggy Promise stuff) is also based on depth number |
| 21:27 | <Domenic> | This was Raf Weinstein's design I believe |
| 21:27 | <esprehn> | upon returning to the event loop we always perform a checkpoint as well |
| 21:27 | <Domenic> | Something about ensuring that the order of the mutation observers are notified is the same as the order they were subscribed in |
| 21:27 | <Domenic> | So you just have a single microtask that then runs through all the mutation observers or something. That's what a compound microtask is, I think. |
| 21:27 | <esprehn> | which catches cases like editing or the parser mutating without calling into script |
| 21:28 | <Domenic> | (whereas if you used normal microtasks it would just notify in the order that the mutations happened, which is for some reason not desired) |
| 21:28 | <esprehn> | Domenic: microtask processing in the spec is pretty confusing. I wish this was more pseudo code like. |
| 21:28 | <esprehn> | :) |
| 21:29 | <Domenic> | esprehn: concrete suggestions would be helpful; from my perspective it's pretty straightforward and algorithmic, but I'm sure I'm just too deep into it. |
| 21:29 | <Domenic> | Anyway yeah tomorrow someone should dig up the old bugs where I'm sure Hixie and raf had a long back and forth designing this system |
| 21:31 | <esprehn> | for starters the spec should define what the two types are |
| 21:32 | <esprehn> | it just mentions them and the links back are to the mentions, not to descriptions of their purpose |
| 21:33 | <Domenic> | ah i see yeah |
| 21:33 | <smaug> | oh yeah, I was wondering what "solitary callback microtasks" are couple of days ago. |
| 21:41 | <smaug> | the spec doesn't really guarantee ordering of MO. If callback for MO A modifies DOM, MO's after A will get notified first, since callback for MO A will be called only after 'perform a microtask checkpoint' is called the next time |
| 21:41 | <smaug> | hmm |