Closed
Bug 201180
Opened 23 years ago
Closed 23 years ago
mozilla's AtkUtil implementation doesn't support atk_add_key_event_listener
Categories
(Core :: Disability Access APIs, defect)
Tracking
()
RESOLVED
FIXED
People
(Reporter: bill.haneman, Assigned: yinbolian)
Details
Attachments
(1 file)
|
6.94 KB,
patch
|
yuanyi21
:
review+
|
Details | Diff | Splinter Review |
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.1) Gecko/20021003
Build Identifier: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.1) Gecko/20021003
If I add a "toolkit key event listener" via a call to
atk_add_key_event_listener(), I should be getting callbacks from the ATK
implementing toolkit (in this case, Mozilla) for every keypress received
by the toolkit/application.
In Mozilla I don't get any event callbacks. The "atk-bridge" registers
such a listener so that events received by the toolkit can be
intercepted and (potentially) consumed. See bugzilla.gnome.org bug
100850 for more information.
Reproducible: Always
Steps to Reproduce:
1.obtain a running gnome-2.2 stack with accessibility "turned on"
2.run the 'key-listener-test' client or run gnopernicus with mozilla
3.focus mozilla, note that gnopernicus or another client of at-spi
which is listening for key events at the 'toolkit level' won't get
key notifications.
Actual Results:
expected key events were not received by the AT client via at-spi
and the atk-bridge.
Expected Results:
Mozilla should implement the atk_key_event_listener API in its
implementation of AtkUtil, and send key notifications via the
callback mechanism there. If the callback consumes the event,
Mozilla should remove that event from the key event queue/stream
which would go onwards to the Mozilla component.
| Assignee | ||
Comment 3•23 years ago
|
||
I'll come to this after the atk accessibility reorg bugs (see 202388)
Status: NEW → ASSIGNED
| Reporter | ||
Comment 4•23 years ago
|
||
202388 doesn't seem to be the right number for the "accessibility reorg" bug
what is the right number?
| Assignee | ||
Comment 5•23 years ago
|
||
Sorry. The right bug for accessibility reorg is: bug 199060 and bug 202085 (for atk)
| Assignee | ||
Comment 6•23 years ago
|
||
| Assignee | ||
Updated•23 years ago
|
QA Contact: dsirnapalli → jessie.li
| Assignee | ||
Updated•23 years ago
|
Attachment #123112 -
Flags: review?(kyle.yuan)
Comment on attachment 123112 [details] [diff] [review]
patch
Bolian, I can't see how your patch listens to mozilla's keypress event and
passes it to AT apps. Can you give me more details?
| Assignee | ||
Comment 8•23 years ago
|
||
this patch implement two atk "virtual functions", like this:
+ atk_class->add_key_event_listener = mai_util_add_key_event_listener;
+ atk_class->remove_key_event_listener = mai_util_remove_key_event_listener;
these two functions are used for AT apps to add/remove key listeners
The main point in mai_util_add_key_event_listener is:
+ key_snooper_id = gtk_key_snooper_install(mai_key_snooper, NULL);
that line add mai_key_snooper as a listener for gdk key press event. So when
there is key press event, "mai_key_snooper" get called in gtk main loop before
that event pass to Mozilla. "mai_key_snooper" will in turn translate and pass
that event to AT app listeners.
Comment on attachment 123112 [details] [diff] [review]
patch
Okay, that's fine :) r=kyle
Attachment #123112 -
Flags: review?(kyle.yuan) → review+
| Assignee | ||
Comment 10•23 years ago
|
||
checked in trunk.
Status: ASSIGNED → RESOLVED
Closed: 23 years ago
Resolution: --- → FIXED
You need to log in
before you can comment on or make changes to this bug.
Description
•