On Mon Feb 6 16:43:23 2023 +0000, Jacek Caban wrote:
Things like `preventDefault()` will not work for dispatches delayed like that. Can we somehow assume that those will be delayed by Gecko?
Not entirely sure. I don't think it does something special in regards to defaults, but in nsXMLHttpRequest::Send (dom/base/nsXMLHttpRequest.cpp) in the sync spin loop, it does suspend all events that end up on the document during capture (suspendedDoc->SuppressEventHandling), as well as timeouts (which we don't care about), which means all the element events.
Now the question is if there's any events that are not suspended by that in Gecko which have a default… Async XHR events for example, don't have a default, I believe, so those should be safe to be queued? Message events aren't blocked, but we don't use Gecko's message events, so they're irrelevant. Same with storage events.
Maybe the question should be, can you think of an event that does? I hope not, because I've no idea how to fix it if there is… :)
Regardless, I should add a comment to that effect when queuing the event, to say why it should work unless we find an event that doesn't, because it's not obvious.
I also found some other small issues that I will fix (`sync_xhr_send` should also check the queued_xhr_events_list when posting the msg; and I think for sync XHRs <= IE9 we should send all the readystatechange events prior to any progress events also, if any, if we haven't yet, but unfortunately this is hard to test, so it's just safer to fix it).