this causes asserts because firing the event causes us to run script which tries to close a window which of course causes a reflow while NotificationController is processing updates. This passes all tests, but I'm not sure hwo many asserts it fixes on !linux yet.
Created attachment 726005 [details] [diff] [review]
this is also good because it means these events participant in coalescence logic.
(In reply to Trevor Saunders (:tbsaunde) from comment #1)
> this is also good because it means these events participant in coalescence
only if busy state change event (if somebody plays with aria-busy on loading document)
[note to myself] so we just fire document load/state busy events after all events in the queue. Taking into account we could fire some events on the document content before this point then it shouldn't be bad.
Trev, do you think to do the same for generic notification processing?
Comment on attachment 726005 [details] [diff] [review]
Review of attachment 726005 [details] [diff] [review]:
> Trev, do you think to do the same for generic notification processing?
yes I think so
ewong's about to back this out for bustage, so I won't set target milestone, but I'll set assignee while I'm here. :D
TEST-UNEXPECTED-FAIL | chrome://mochitests/content/a11y/accessible/events/test_scroll.xul | Test timed out
Jamie this will make it somewhat more likely that scrolling start will fire before document load (which could already happen in some cases) Could that be a problem for you?
It's not a problem if scrolling start fires before document load. However, it mustn't fire before initial focus.
(In reply to James Teh [:Jamie] from comment #8)
> It's not a problem if scrolling start fires before document load. However,
> it mustn't fire before initial focus.
we preserve ordering of scroll start event wrt immediately preceeding focus event so this should be ok.
then it makes change events order in the test
(In reply to alexander :surkov from comment #10)
> then it makes change events order in the test
wouldn't it be better to make them asyncInvokerCheckers since they can technically race?
up to you
kill more expected assertion stuff