Closed
Bug 615189
Opened 14 years ago
Closed 14 years ago
clean up FireAccessibleFocusEvent
Categories
(Core :: Disability Access APIs, defect)
Core
Disability Access APIs
Tracking
()
RESOLVED
FIXED
mozilla2.0b8
People
(Reporter: surkov, Assigned: surkov)
References
(Blocks 1 open bug)
Details
(Keywords: access)
Attachments
(2 files, 2 obsolete files)
22.43 KB,
patch
|
fherrera
:
review+
|
Details | Diff | Splinter Review |
14.60 KB,
patch
|
fherrera
:
review+
davidb
:
approval2.0+
|
Details | Diff | Splinter Review |
No description provided.
Attachment #493663 -
Flags: review?(marco.zehe)
Attachment #493663 -
Flags: review?(fherrera)
Attachment #493663 -
Flags: approval2.0?
Comment 1•14 years ago
|
||
Comment on attachment 493663 [details] [diff] [review] patch r=me for the tests, thanks!
Attachment #493663 -
Flags: review?(marco.zehe) → review+
Comment 2•14 years ago
|
||
test_menu.xul is giving a timeout on linux. That is probably because VK_ALT is not focusing the menu bar. we could use: synthesizeKey("F", { altKey: true }); but that would open the file popup and focus the newtab node.
Comment 3•14 years ago
|
||
ok, alt is not focusing the menu bar because of the default linux preferences. It's going to be tricky to test this under linux, because even if we add this to the test: var prefs = Components.classes["@mozilla.org/preferences-service;1"].getService(Components.interfaces.nsIPrefBranch); prefs.setBoolPref("ui.key.menuAccessKeyFocuses", true); that pref is loaded only at init time at nsMenuBarListener::InitAccessKey that happens before the js code gets executed. Hardcoding the preference to test this, I'm getting: Event queue: invoke: activate menubar Event type: menu start. Target: [ 'menubar@id='menubar' node' , role: menubar, name: 'Application', address: 0xa5144ec0]. Listeners count: 1 ***** EQ matched: menu start ***** Event type: focus. Target: [ 'menu@id='menufile' node' , role: parent menuitem, name: 'File', address: 0xa515ace0]. Listeners count: 1 ***** EQ matched: focus ***** Event queue: invoke: move to next menu Event type: focus. Target: [ 'menu@id='menuedit' node' , role: parent menuitem, name: 'Edit', address: 0xa6c7f470]. Listeners count: 1 ***** EQ matched: focus ***** Event queue: invoke: open menu Event type: focus. Target: [ 'menuitem@id='menuitemundo' node' , role: menuitem, name: 'Undo', address: 0xa51e6740]. Listeners count: 1 Instead of the expected menupopup start for menupopupedit Anyway, I have been testing windows build and the alt for menu activation is behaving in a different way.
Assignee | ||
Comment 4•14 years ago
|
||
Attachment #493663 -
Attachment is obsolete: true
Attachment #494034 -
Flags: review?(fherrera)
Attachment #493663 -
Flags: review?(fherrera)
Attachment #493663 -
Flags: approval2.0?
Assignee | ||
Comment 5•14 years ago
|
||
try server build - http://ftp.mozilla.org/pub/mozilla.org/firefox/tryserver-builds/surkov.alexander@gmail.com-10fb57788c90
Comment 6•14 years ago
|
||
Hum, I saw the try server tests still failing under linux. Tried with debug options, and those are the events I'm seeing: Event queue: invoke: open file menu by alt+F press Event type: menu start. Target: [ 'menubar@id='menubar' node' , role: menubar, name: 'Application', address: 0xa5750e70]. Listeners count: 1 Event type: focus. Target: [ 'menuitem@id='menuitem-newtab' node' , role: menuitem, name: 'New Tab', address: 0xa6ed1240]. Listeners count: 1 Event queue: invoke: open edit menu by lef arrow press Event type: focus. Target: [ 'menu@id='menuitem-edit' node' , role: parent menuitem, name: 'Edit', address: 0xa5beda60]. Listeners count: 1 Event type: focus. Target: [ 'menuitem@id='menuitem-undo' node' , role: menuitem, name: 'Undo', address: 0xafc917e0]. Listeners count: 1 Event queue: invoke: close edit menu, leave menubar Event type: focus. Target: [ 'document node' , role: application, name: 'Accessible menu events testing for XUL menu', address: 0xa570ea5c] Event type: menu end. Target: [ 'menubar@id='menubar' node' , role: menubar, name: 'Application', address: 0xa5750e70]. Listeners count: 1 So it looks like we are missing EVENT_MENUPOPUP_START/END events.
Comment 7•14 years ago
|
||
Feedback on this try-server build: 1. Menus work with both JAWS and NVDA as expected. 2. The Youtube problem I describe with JAWS on bug 615520 is NOT present in this try server build. This build is good from my end!
Comment 8•14 years ago
|
||
Umm, that was supposed to read bug 615220 comment#5.
Assignee | ||
Comment 9•14 years ago
|
||
(In reply to comment #8) > Umm, that was supposed to read bug 615220 comment#5. Marco, what about latest try server build in bug bug 615220?
Assignee | ||
Comment 10•14 years ago
|
||
Attachment #494034 -
Attachment is obsolete: true
Attachment #494668 -
Flags: review?(fherrera)
Attachment #494034 -
Flags: review?(fherrera)
Assignee | ||
Comment 11•14 years ago
|
||
Attachment #494669 -
Flags: review?(fherrera)
Comment 12•14 years ago
|
||
Comment on attachment 494668 [details] [diff] [review] tests: patch1 tests looks good, even if not passing under linux :) r=me
Attachment #494668 -
Flags: review?(fherrera) → review+
Assignee | ||
Comment 13•14 years ago
|
||
part1 is landed on 2.0 http://hg.mozilla.org/mozilla-central/rev/eb4d2a3dc388
Comment 14•14 years ago
|
||
Comment on attachment 494669 [details] [diff] [review] cleanup: patch1 r=me for the cleanup too
Attachment #494669 -
Flags: review?(fherrera) → review+
Assignee | ||
Updated•14 years ago
|
Attachment #494669 -
Flags: approval2.0?
Updated•14 years ago
|
Attachment #494669 -
Flags: approval2.0? → approval2.0+
Assignee | ||
Comment 15•14 years ago
|
||
landed on 2.0 - http://hg.mozilla.org/mozilla-central/rev/711d073c2338
Status: ASSIGNED → RESOLVED
Closed: 14 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla2.0b8
Comment 16•14 years ago
|
||
Note test_menu fails for me on mac.
You need to log in
before you can comment on or make changes to this bug.
Description
•