Closed Bug 615189 Opened 14 years ago Closed 14 years ago

clean up FireAccessibleFocusEvent

Categories

(Core :: Disability Access APIs, defect)

defect
Not set
normal

Tracking

()

RESOLVED FIXED
mozilla2.0b8

People

(Reporter: surkov, Assigned: surkov)

References

(Blocks 1 open bug)

Details

(Keywords: access)

Attachments

(2 files, 2 obsolete files)

Attached patch patch (obsolete) — Splinter Review
      No description provided.
Attachment #493663 - Flags: review?(marco.zehe)
Attachment #493663 - Flags: review?(fherrera)
Attachment #493663 - Flags: approval2.0?
Comment on attachment 493663 [details] [diff] [review]
patch

r=me for the tests, thanks!
Attachment #493663 - Flags: review?(marco.zehe) → review+
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.
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.
Attached patch patch2 (obsolete) — Splinter Review
Attachment #493663 - Attachment is obsolete: true
Attachment #494034 - Flags: review?(fherrera)
Attachment #493663 - Flags: review?(fherrera)
Attachment #493663 - Flags: approval2.0?
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.
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!
Umm, that was supposed to read bug 615220 comment#5.
(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?
Attached patch tests: patch1Splinter Review
Attachment #494034 - Attachment is obsolete: true
Attachment #494668 - Flags: review?(fherrera)
Attachment #494034 - Flags: review?(fherrera)
Attached patch cleanup: patch1Splinter Review
Attachment #494669 - Flags: review?(fherrera)
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+
Comment on attachment 494669 [details] [diff] [review]
cleanup: patch1

r=me for the cleanup too
Attachment #494669 - Flags: review?(fherrera) → review+
Attachment #494669 - Flags: approval2.0?
Attachment #494669 - Flags: approval2.0? → approval2.0+
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
Depends on: 618779
Note test_menu fails for me on mac.
No longer depends on: 618779
Depends on: 618779
Depends on: 634240
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: