413675 - dropdown menu button - incorrect accessibility events

Status: RESOLVED FIXED

(Core :: Disability Access APIs, defect)

Description

[Becky Gibson]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9b3pre) Gecko/2008012304 Minefield/3.0b3pre
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9b3pre) Gecko/2008012304 Minefield/3.0b3pre

There seem to be too many events generated when a Dojo dropdown menu button is invoked.  The events seem to be correct in FF 2.0.0.11 but not in Minefield.
Here is a brief overview of how the menu associated with the dropdown button is created:
<table role="menu">
	<tbody>
	<tr>
		<td><div>styled for menu icon></div></td>
		<td role=menuitem tabindex=-1>menutext</td>
		<td><div> possible arrow icon if menuitem has submenu - may be display:none<span>high contrast text icon</span></div></td>
	</tr>
	</tbody>
</table>

When I tab to the Edit Button and press Enter here is what AccEvent shows for FF2:
OBJ_FOCUS	 Name="Edit!" Role=push button State=focused,focusable,has popup
OBJ_FOCUS	 Name="Cut" Role=menu item State=focused
OBJ_SHOW	 Name="" Role=popup menu State=normal

And here is what I see for Minefield:
OBJ_FOCUS	 Name="Edit!" Role=push button State=focused,focusable,has popup
OBJ_FOCUS	 Name="Cut" Role=menu item State=focused,focusable
OBJ_SHOW	 Name=none [null] Role="div" [ BUG? State/Role should not be a string ] State=floating
OBJ_HIDE	 Name=none [null] Role="tr" [ BUG? State/Role should not be a string ] State=focusable
OBJ_HIDE	 Name=none [null] Role="tr" [ BUG? State/Role should not be a string ] State=focusable
OBJ_HIDE	 Name=none [null] Role="div" [ BUG? State/Role should not be a string ] State=normal
OBJ_HIDE	 Name=none [null] Role="div" [ BUG? State/Role should not be a string ] State=normal
OBJ_HIDE	 Name=none [null] Role="div" [ BUG? State/Role should not be a string ] State=normal
OBJ_HIDE	 Name=none [null] Role="div" [ BUG? State/Role should not be a string ] State=normal
OBJ_HIDE	 Name=none [null] Role="div" [ BUG? State/Role should not be a string ] State=normal
OBJ_SHOW	 Name=none [null] Role="div" [ BUG? State/Role should not be a string ] State=floating

The table does NOT have a presentation role - perhaps it should?

Reproducible: Always

Steps to Reproduce:
1. in Windows open http://archive.dojotoolkit.org/dojo-2008-01-23/dojotoolkit/dijit/tests/form/test_Button.html
2. load AccEvent - filter the events to obj_focus, obj_statechange, etc
3.tab to Edit button and press enter
4. note the events generated that have no role information
Actual Results:  
results differ in FF 2.0.0.11 and Minefield.  Also focus behaves differently. In FF 2 the first menu item is highlighted when it is opened, in Minefield focus jumps to the second menu item.

Comment 1

[Aaron Leventhal]

I'm getting different results:

* The first item is getting focused, not the second, which is correct
* I'm not getting any hide events
* I'm getting the correct focus events.

I do see extra show events but I don't believe they're really a problem for JAWS.

Really the biggest concern is the flood menupopupstart events (I have that turned on in my event watcher as well). There should only be one. Simon worked on a similar problem for Dojo menus before and I thought progress had been made. Based on the way Dojo was putting menus up, it was very difficult for Mozilla to make sense of it and fire the right events.

Comment 2

[Simon Bates]

I've created a ticket for the extra menupopupstart events and will investigate in Dojo:

http://trac.dojotoolkit.org/ticket/4616

Comment 3

[Ginn Chen]

FWIW:
On Solaris, I got
3 focus events
1) push button "Edit!"
2) menu item "Cut"
3) menu
and I got 7 state-changed:visible and 7 state-changed:showing events for the "menu"

And I got quite a lot asserts in console
###!!! ASSERTION: No accessible for parent table and it didn't have role of presentation: 'roleMapEntry && !nsCRT::strcmp(roleMapEntry->roleString, "presentation")', file nsAccessibilityService.cpp, line 144

The roleString is "menu".

Comment 4

[Simon Bates]

Attachment: table_menu_events.html

testcase, generates 4 MENUPOPUPSTART events

Comment 5

[Simon Bates]

Firefox generates multiple MENUPOPUPSTART events whenever a table with role="menu" has its visibility style changed from "hidden" to "visible".

To reproduce:

* run the Microsoft AccEvent tool
* open the attached table_menu_events.html [I used Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9b3pre) Gecko/2008020404 Minefield/3.0b3pre]
* click "open menu"
* 4 MENUPOPUPSTART events are logged by AccEvent

Comment 6

[Aaron Leventhal]

Menu events must be perfectly nested.

What we need to do is have a stack object that tracks what menus have been opened.

1. Don't fire a menupopupstart for something already in that stack
2. If something gets focused who's parent is not a menu, that means menus are now closed, and we should fire menupopupend events for everything in the stack, in reverse order.

Surkov, can you handle this one?

Comment 7

[alexander :surkov (:asurkov)]

Attachment: patch

simple case, for the attached testcase. Aaron could you upload testcase what you keep in mind?

Comment 8

[Aaron Leventhal]

Comment on attachment 302765 [details] [diff] [review]
patch

Let's get this in and see if Dojo has any more issues.

Comment 9

[Aaron Leventhal]

Checked in for Surkov.

Comment 10

[Simon Bates]

I confirm that this change to Mozilla fixes the multiple SYS_MENUPOPUPSTART events on the Dojo menu. Now, one SYS_MENUPOPUPSTART is generated, followed by one SYS_MENUPOPUPEND on menu close.

Thanks!