http://archive.dojotoolkit.org/nightly/dojotoolkit/dijit/test/form/test_Button.html Tab to save button dropmarker and hit Enter. The MSAA focus event for the Save menuitem should occur after the menupopupstart.

This is an event reordering problem, so I want to wait for Ginn's event reordering work in bug 418845.

Better URL: http://archive.dojotoolkit.org/nightly/dojotoolkit/dijit/tests/form/test_Button.html

The focus events and some other events were actually being fired on the root accessible even when they occurred in an inner doc accessible. So they were on a different event queue than the menupopup start. That's just a mess and everything gets cleared up when each top level window has one event queue.

Marco, here are test builds. Please make sure that eventing still works as it does now. It would be good to test various HTML, XUL and ARIA scenarios: https://build.mozilla.org/tryserver-builds/2008-03-23_22:13-aaronleventhal@moonset.net-OneEventQueuePerRootAccessible/

With a regular nightly, I see the following behavior with the last testing URL you posted: 1. I load the dojo page. 2. Page comes up, drops JAWS virtual cursor in the textbox. 3. I turn off virtual cursor and go to the"Edit!" menu button and press it. Result: Menu comes up, but JAWS does not announce this. Braille indicates it, however. Arrowing inside the menu is fine, also opening and closing sub menus does not cause problems. 4. I press ESCAPE to close the menu. Result: JAWS correctly announces that the menus have closed, and that I am back on the "Edit!" menu button. With the try-server build: 1. I load the page. Result: JAWS immediately announces that a menu came active even though I have not yet pressed any of the menu buttons. 2. I go to the file menu, then press ESCAPE to get JAWS back into a "menu closed" state. 3. I then turn off virtual cursor and press the "Edit!" menu button. Result: JAWS announces that the menu came active. I can arrow through it, open and close sub menus without problems. 4. I press ESCAPE to close the menu. Result: JAWS does not notice that the menu became inactive. Even though focus is reported to be on the "Edit!" menu button again, JAWS still thinks that the menu is active. Now if you could combine the two behaviors that would be awesome! :-) Most importantly: JAWS should not immediately think that a menu was activated once I load that page, and second it should recognize that the menus closed. The focus event on the button must come *after* the menupopupclose and menuclose events. And the close events should be in the order "popupclose", then "menuclose". Likewise, "menustart" should come first, then "popupstart".

Ping on this - we are past RC1 code freeze - so we either need to review/land this or it waits until a dot release...

Mike, I think it's too risky at this point. If there's a Firefox 3.1 release it would be great for ARIA. We have about 6 items we'd like to do if that release happens. We'll probably get 6 more during various spec reviews and discussions with Opera and Microsoft. Otherwise I guess we have to wait 2 years which would be unfortunate. At least there is a workaround which is for the ARIA widget developer to have a very clean widget implementation.

s/clean widget implementation/clean menu implementation

Aaron - we'll likely have a second smaller release this year - so there shouldn't be need to wait 2 years. Taking this off the FF3 blocker list.

What's the status of the bug? Is/should be comment #5 addressed before I should do review?

Comment on attachment 311325 [details] [diff] [review] Single event queue per window (nsRootAccessible) instead of per-doc allows the event rule processing to function properly It needs work because of the issues Marco found.

Any update here?

I received a report from one of the commercial screen reader vendors that this same problem also is valid for the order in which regular SYS_MENUSTART, SYS_MENUPOPUPSTART etc. are sometimes. I suspect that once we fix this bug, regular menus will also be fixed. Would anyone want to pick this one up again and work on it?

Marco in terms of prioritizing, is there currently a workaround, or is this bug hurting the vendor's users?

I'm going to unassign this until I'm really active on it, in case someone else can take it. It seems to me we might want to reconsider one event queue per window (currently we use per doc which is nice is some ways).

We need to consider this as blocking. AT depends on events order and per document queue makes events firing random. For example, order of reorder and focus events may be random, so that AT may have out of date virtual buffer and handle focus event for something that is not in their buffer. This issue is staying unresolved for a long time. We need to get it fixed in Firefox 4, it should be a really good improvement of Firefox 4 a11y. We have a patch, so it shouldn't be very hard.

Good catch. I agree this should block and the fix might be simpler now. Assigning to Alexander as per IRC.

I think it makes sense to have event queue per tab document. We don't need keep events together from all tabs and it might be issue with ongoing multi-threaded browser. Though this makes a fix tricky.

I don't see menupopup_start in Firefox 3.6. The order of menupopup start and focus events is correct in Firefox 4, but it depends on timing so we're just lucky. And eventually menupopup end was removed from Firefox 4. We need to resurrect it. I'll file a bug for that.

fire a11y events created during DOM event handling and a11y focus event to the queue of document where event target is hosted.

Event queue per root and tab documents only. The event queue should be flushed when all document that it relates to gets refresh. This patch listens refresh of own document.

Comment on attachment 493912 [details] [diff] [review] part1: patch1 looks ok, r=me

part1 landed - http://hg.mozilla.org/mozilla-central/rev/cef32fff6f24

(In reply to comment #21) > Created attachment 493913 [details] [diff] [review] > part2: wip > What work remains here?

idea behind the bug makes sense, keep events order consistent. I think it'll be nice to find some examples to show the problem. From implementation point of view I'm not sure how it affects on multiple processes architecture since it makes sense to keep event queue per process.

I think this bug can be marked as fixed because events targeted to the same document are processed by that document event queue, that means we shouldn't hit the problem until ARIA widget is spread through two documents. So I'm not sure if it's necessary to have one event queue per tab document (obviously it complicates the code). I can think of one example only where it's needed. Keep reorder event on document container in sync with events for document (currently they belong to different event queues and therefore processed independently from each other). But it appears nobody cares they aren't in sync. See bug 669263 for details. I suggest to get back to this bug if we find other usecases.