After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 334933 - AccessibleEvent's source is always 'main' for 'mouse:*' events
AccessibleEvent's source is always 'main' for 'mouse:*' events
Status: RESOLVED NOTABUG
Product: at-spi
Classification: Platform
Component: general
unspecified
Other Linux
: Normal normal
: ---
Assigned To: bill.haneman
bill.haneman
Depends on:
Blocks: 318538
 
 
Reported: 2006-03-17 22:02 UTC by Zack Cerza
Modified: 2006-03-20 17:55 UTC
See Also:
GNOME target: ---
GNOME version: ---


Description Zack Cerza 2006-03-17 22:02:17 UTC 
While working on a recorder for dogtail, I noticed that the mouse click events were reporting the wrong source - the desktop ('main') to be precise. I first wrote up short test script using pyspi, but after a quick googling I found at-spi/test/event-listener-test. It exhibits the same problem.

If I click on an app's 'File' menu, I expect the source of the AccessibleEvent to be an Accessible with a role name of 'menu' and a name of 'File'.
Comment 1 bill.haneman 2006-03-18 10:55:53 UTC 
"mouse" events are not GUI component events, but device events.  As such, they do not originate at the widget.

This is not a bug.  If you want events whose source object is a GUI interface component, you must listen for state-change events.
Comment 2 Zack Cerza 2006-03-20 15:12:14 UTC 
Odd... I've never seen that event ("state-changed:") fire. I should probably file a separate bug on that, then.
Comment 3 bill.haneman 2006-03-20 15:14:36 UTC 
RE: state-changed... you won't see it if you don't register for it (via Accessibility_Registry_registerGlobalEventListener...)
Comment 4 Zack Cerza 2006-03-20 17:39:27 UTC 
Right; I'm aware of that. I'm registering for it and not seeing it fired.
Comment 5 bill.haneman 2006-03-20 17:50:42 UTC 
I take it you've seen at-spi/tests/event-listener-test, which registers for and prints info on these events (run it in an xterm, not a gnome-terminal)?

Menu items don't emit the same events as buttons, but you should be seeing active-descendant-changed events on the containing menu.  Make sure you update your gail.
Comment 6 Zack Cerza 2006-03-20 17:55:47 UTC 
Ooh, I take that back: I've just gotten state-changed to work in the last 2 minutes. Now to play with it for a while, and see if it gives me enough information...