Last Comment Bug 422744 - For ARIA menupopup, focus event for new menuitem must be after menupopupstart event
: For ARIA menupopup, focus event for new menuitem must be after menupopupstart...
Breaks access to Dojo and other JS me...
: access
Product: Core
Classification: Components
Component: Disability Access APIs (show other bugs)
: unspecified
: All Windows XP
P2 normal (vote)
: mozilla2.0
Assigned To: alexander :surkov
: alexander :surkov
Depends on: 418845
Blocks: aria focuseventa11y eventa11y
  Show dependency treegraph
Reported: 2008-03-13 12:21 PDT by Aaron Leventhal
Modified: 2011-07-18 04:25 PDT (History)
11 users (show)
mtschrep: wanted‑next+
mtschrep: blocking1.9-
See Also:
Crash Signature:
QA Whiteboard:
Iteration: ---
Points: ---
Has Regression Range: ---
Has STR: ---

Single event queue per window (nsRootAccessible) instead of per-doc allows the event rule processing to function properly (24.36 KB, patch)
2008-03-23 22:11 PDT, Aaron Leventhal
ginn.chen: review+
Details | Diff | Splinter Review
part1: patch1 (6.44 KB, patch)
2010-11-29 22:14 PST, alexander :surkov
fherrera: review+
Details | Diff | Splinter Review
part2: wip (9.49 KB, patch)
2010-11-29 22:16 PST, alexander :surkov
no flags Details | Diff | Splinter Review

Description User image Aaron Leventhal 2008-03-13 12:21:53 PDT

Tab to save button dropmarker and hit Enter. The MSAA focus event for the Save menuitem should occur after the menupopupstart.
Comment 1 User image Aaron Leventhal 2008-03-14 08:01:18 PDT
This is an event reordering problem, so I want to wait for Ginn's event reordering work in bug 418845.
Comment 3 User image Aaron Leventhal 2008-03-23 22:11:21 PDT
Created attachment 311325 [details] [diff] [review]
Single event queue per window (nsRootAccessible) instead of per-doc allows the event rule processing to function properly

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.
Comment 4 User image Aaron Leventhal 2008-03-23 23:41:42 PDT
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:
Comment 5 User image Marco Zehe (:MarcoZ) 2008-03-24 00:08:01 PDT
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".
Comment 6 User image Mike Schroepfer 2008-04-11 09:55:54 PDT
Ping on this - we are past RC1 code freeze - so we either need to review/land this or it waits until a dot release...
Comment 7 User image Aaron Leventhal 2008-04-11 12:03:13 PDT
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.
Comment 8 User image Aaron Leventhal 2008-04-11 12:03:30 PDT
s/clean widget implementation/clean menu implementation
Comment 9 User image Mike Schroepfer 2008-04-12 11:37:31 PDT
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.
Comment 10 User image alexander :surkov 2008-04-14 06:30:35 PDT
What's the status of the bug? Is/should be comment #5 addressed before I should
do review?
Comment 11 User image Aaron Leventhal 2008-04-14 08:25:50 PDT
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.
Comment 12 User image Samuel Sidler (old account; do not CC) 2008-08-17 15:54:46 PDT
Any update here?
Comment 13 User image Marco Zehe (:MarcoZ) 2009-04-21 02:24:52 PDT
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?
Comment 14 User image David Bolter [:davidb] 2009-04-23 11:12:00 PDT
Marco in terms of prioritizing, is there currently a workaround, or is this bug hurting the vendor's users?
Comment 15 User image David Bolter [:davidb] 2010-01-19 06:50:51 PST
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).
Comment 16 User image alexander :surkov 2010-10-14 00:18:43 PDT
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.
Comment 17 User image David Bolter [:davidb] 2010-10-14 06:25:14 PDT
Good catch. I agree this should block and the fix might be simpler now. Assigning to Alexander as per IRC.
Comment 18 User image alexander :surkov 2010-10-21 08:09:03 PDT
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.
Comment 19 User image alexander :surkov 2010-11-25 07:48:38 PST
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.
Comment 20 User image alexander :surkov 2010-11-29 22:14:14 PST
Created attachment 493912 [details] [diff] [review]
part1: patch1

fire a11y events created during DOM event handling and a11y focus event to the queue of document where event target is hosted.
Comment 21 User image alexander :surkov 2010-11-29 22:16:21 PST
Created attachment 493913 [details] [diff] [review]
part2: wip

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 22 User image Fernando Herrera 2010-12-02 12:30:45 PST
Comment on attachment 493912 [details] [diff] [review]
part1: patch1

looks ok, r=me
Comment 23 User image alexander :surkov 2010-12-13 14:10:26 PST
part1 landed -
Comment 24 User image David Bolter [:davidb] 2011-04-27 11:23:52 PDT
(In reply to comment #21)
> Created attachment 493913 [details] [diff] [review]
> part2: wip

What work remains here?
Comment 25 User image alexander :surkov 2011-05-12 04:57:20 PDT
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.
Comment 26 User image alexander :surkov 2011-07-18 04:25:02 PDT
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.

Note You need to log in before you can comment on or make changes to this bug.