On Thu Feb 9 15:26:12 2023 +0000, Gabriel Ivăncescu wrote:
I found a bit more other issues (some were existing now already), for example with readystatechange tasks. It's deeper than just dispatch_event, they use call_property_onchanged for example, but also dispatch the event. I'm thinking to rewrite this in more generic way using different task lists, one for current tasks, one for event tasks, and one for async XHRs. Then I'll conditionally dispatch or post the event in nsevents (for window), the rest can stay dispatch_event since they're either synchronous or sent to document (on Gecko side, since we care whether it delays them or not).
I'm not sure about the details, but yes, moving delaying code out of `dispatch_event()` (to its callers) seems right. That should make the blocking actually simpler: I think that we don't need depth-based testing. I'd expect that async events should be able to be simply blocked or not.
Using thread data is also a bit questionable. We could have two separated iframes or even totally separated HTML document instances (as in HTMLDocumentObj) and with your solution they'd block each other. I guess that's why Gecko uses per-document blocking. Maybe it would be a good idea to do something similar? Note that even XHRs can be associated with a document that was used to create them.