dropdown menu button - incorrect accessibility events

RESOLVED FIXED

Status

()

RESOLVED FIXED
11 years ago
11 years ago

People

(Reporter: gibson.becky, Assigned: surkov)

Tracking

(Blocks: 1 bug)

Firefox Tracking Flags

(Not tracked)

Details

(URL)

Attachments

(2 attachments)

(Reporter)

Description

11 years ago
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.

Updated

11 years ago
Assignee: nobody → aaronleventhal
Blocks: 343213
Component: Disability Access → Disability Access APIs
Product: Firefox → Core
QA Contact: disability.access → accessibility-apis

Comment 1

11 years ago
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

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

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

Comment 3

11 years ago
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

11 years ago
Created attachment 301354 [details]
table_menu_events.html

testcase, generates 4 MENUPOPUPSTART events

Comment 5

11 years ago
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

11 years ago
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?
Assignee: aaronleventhal → surkov.alexander
(Assignee)

Comment 7

11 years ago
Created attachment 302765 [details] [diff] [review]
patch

simple case, for the attached testcase. Aaron could you upload testcase what you keep in mind?
Attachment #302765 - Flags: review?(aaronleventhal)
(Assignee)

Updated

11 years ago
Status: UNCONFIRMED → ASSIGNED
Ever confirmed: true

Comment 8

11 years ago
Comment on attachment 302765 [details] [diff] [review]
patch

Let's get this in and see if Dojo has any more issues.
Attachment #302765 - Flags: review?(aaronleventhal)
Attachment #302765 - Flags: review+
Attachment #302765 - Flags: approval1.9?

Updated

11 years ago
Attachment #302765 - Flags: approval1.9? → approval1.9+

Comment 9

11 years ago
Checked in for Surkov.
Status: ASSIGNED → RESOLVED
Last Resolved: 11 years ago
Resolution: --- → FIXED

Comment 10

11 years ago
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!
You need to log in before you can comment on or make changes to this bug.