On Tue Feb 7 15:00:46 2023 +0000, Gabriel Ivăncescu wrote:
From what I can see, Gecko only suppresses events that reach the document. So, all nodes (and thus elements) linked to the document. The ones unlinked won't generate any events, anyway, so that's fine. It also suppresses timeouts (those are on the window), but nothing else. However this is not important because we don't use Gecko's timeouts anyway. Other events that are *not* linked to the document and aren't delayed by Gecko:
- Async XHR events (the biggest issue)→but these don't have defaults on
Gecko AFAIK, so should be fine.
- Message events (posted to window)→we don't use Gecko's anyway.
- Storage events, but again, we don't use Gecko's anyway, so it's fine.
- Possibly other such similar events? That said, such events would need
to be sent/posted by Gecko before the event spin loop or during it to pose a problem. *And* they'd need to have defaults (on Gecko, not IE). I did mention in the comment but it's probably not very obvious. If you have suggestions how to reword the comment please let me know.
Back to my question, it's "none that we care", right? In that case, I'm not sure if event dispatcher is the right place to handle it. We already have some custom delaying code both for Message and Storage events, we could probably replace it by something like `post_event()` that would take care of both blocked delays. For XHR we need a separated mechanism anyway.