Closed
Bug 240541
Opened 20 years ago
Closed 13 years ago
Mozilla/GOK problems with modal windows
Categories
(Core :: Disability Access APIs, defect)
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.
Comment 1•20 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.
Updated•20 years ago
|
Blocks: aix-access
Comment 2•20 years ago
|
||
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? :)
Comment 3•20 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 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.
Updated•20 years ago
|
Assignee: aaronleventhal → pkw
Reporter | ||
Updated•19 years ago
|
Assignee: pkwarren → aaronleventhal
Comment 5•13 years ago
|
||
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
Updated•13 years ago
|
Whiteboard: [bk1]
You need to log in
before you can comment on or make changes to this bug.
Description
•