Closed
Bug 413675
Opened 15 years ago
Closed 15 years ago
dropdown menu button - incorrect accessibility events
Categories
(Core :: Disability Access APIs, defect)
Tracking
()
RESOLVED
FIXED
People
(Reporter: gibson.becky, Assigned: surkov)
References
(Blocks 1 open bug, )
Details
Attachments
(2 files)
523 bytes,
text/html
|
Details | |
1.89 KB,
patch
|
aaronlev
:
review+
mtschrep
:
approval1.9+
|
Details | Diff | Splinter Review |
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•15 years ago
|
Assignee: nobody → aaronleventhal
Blocks: aria
Component: Disability Access → Disability Access APIs
Product: Firefox → Core
QA Contact: disability.access → accessibility-apis
Comment 1•15 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•15 years ago
|
||
I've created a ticket for the extra menupopupstart events and will investigate in Dojo: http://trac.dojotoolkit.org/ticket/4616
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•15 years ago
|
||
testcase, generates 4 MENUPOPUPSTART events
Comment 5•15 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•15 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•15 years ago
|
||
simple case, for the attached testcase. Aaron could you upload testcase what you keep in mind?
Attachment #302765 -
Flags: review?(aaronleventhal)
Assignee | ||
Updated•15 years ago
|
Status: UNCONFIRMED → ASSIGNED
Ever confirmed: true
Comment 8•15 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•15 years ago
|
Attachment #302765 -
Flags: approval1.9? → approval1.9+
Comment 9•15 years ago
|
||
Checked in for Surkov.
Status: ASSIGNED → RESOLVED
Closed: 15 years ago
Resolution: --- → FIXED
Comment 10•15 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.
Description
•