Closed Bug 240541 Opened 20 years ago Closed 13 years ago

Mozilla/GOK problems with modal windows

Categories

(Core :: Disability Access APIs, defect)

x86
Linux
defect
Not set
normal

Tracking

()

RESOLVED WONTFIX

People

(Reporter: pkwarren, Unassigned)

References

Details

(Whiteboard: [bk1])

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,
GTK_MODULES, etc.).
- 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.
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.
Blocks: aix-access
More info at http://cvs.gnome.org/viewcvs/gok/README?rev=1.28&view=auto

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? :)

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
AtkAction
* 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.
Assignee: aaronleventhal → pkw
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).
Status: NEW → RESOLVED
Closed: 13 years ago
Resolution: --- → WONTFIX
You need to log in before you can comment on or make changes to this bug.