Mozilla/GOK problems with modal windows




Disability Access APIs
14 years ago
6 years ago


(Reporter: Philip K. Warren, Unassigned)



Firefox Tracking Flags

(Not tracked)


(Whiteboard: [bk1])



14 years ago
I am seeing some problems with the interaction of GOK and Mozilla with modal
windows. This requires testing Mozilla with a build which includes the fix for
Bug 235690 to enable the GOK "Menus" functionality to work.

To reproduce:
- Start GOK.
- Start Mozilla with accessibility support enabled (GNOME_ACCESSIBILITY,
- Hover over the menus in Mozilla to get GOK to activate the "Menus" button.
- Click on the "Menus" button in GOK, then click on the "File" button and then
the "Open File" button.
- The cursor will seem to be locked by GOK now. It is possible to move the
cursor around the screen, however clicking on any item will not work properly.
To restore the use of the mouse, it is necessary to click the "Esc" key to close
the modal "Open File" window.

Comment 1

14 years ago
This is near-unfixable in the general case; if you read the GOK README you will
see that we strongly urge against using GOK in 'corepointer' mode; the user will
invariably get locked out by various toolkits if the user is unable to 'click'
the mouse in the 'normal' manner.  The solution is to drive GOK via actions
defined to use XInput, i.e. make sure the Dwell action is set up to use XInput,
not corepointer, and use "switch" actions via XInput as well, not corepointer
mouse buttons for scanning, etc.  It would be "nice" to fix, but there's really
no way to ensure that various toolkits don't grab the pointer at inopportune times.


14 years ago
Blocks: 239917

Comment 2

14 years ago
More info at

Bill, thanks for explaining. What would be a likely fix in Mozilla, if we chose
to at least fix it in our toolkit? And when is there going to be an important
accessibility conference in Ireland that I'm forced to go to? :)

Comment 3

14 years ago
If you wanted to at least be no more broken than most other toolkits, the best
fix would be to:

* avoid pointer grabs *except* when a menu is posted
* don't post menus when they are queried or their menu items are activated by
* never grab the server while waiting for user action (you probably don't do
this, but just in case ;-)

It would be even better if you avoided pointer grabs during keynav, i.e. only do
a pointer grab on menus if activated by the pointer/mouse.  That may annoy
people who expect a mix-and-match approach to behave exactly like mouse-only
scenario, i.e. they post a menu with the keyboard, then select items on it using
the mouse, and expect identical behavior.  Kind of an edge case IMO, but some
folks would use it to argue against avoiding pointer grabs during keynav
operations in general.

BTW if you want to try GOK in non-corepointer mode (and I highly recommend it),
you'll need to edit your XFree86Config file and make sure your extended mouse
devices don't use AlwaysCore or SendCore.  Then you'll need to run gok
--settings and make the appropriate changes in the Actions pane and Access
Methods pane.


14 years ago
Assignee: aaronleventhal → pkw


13 years ago
Assignee: pkwarren → aaronleventhal
Mass un-assigning bugs assigned to Aaron.
Assignee: aaronleventhal → nobody
Closing as WONTFIX since GOK is stale and it is clear we won't have time to fix this anyways. (Caribou is the new GOK).
Last Resolved: 6 years ago
Resolution: --- → WONTFIX
Whiteboard: [bk1]
You need to log in before you can comment on or make changes to this bug.