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 715179 - Accessible events missing when a context menu first appears
Accessible events missing when a context menu first appears
Status: RESOLVED DUPLICATE of bug 711397
Product: gtk+
Classification: Platform
Component: Accessibility
3.10.x
Other Linux
: Normal normal
: ---
Assigned To: gtk-bugs
gtk-bugs
Depends on:
Blocks:
 
 
Reported: 2013-11-25 16:45 UTC by Joanmarie Diggs (IRC: joanie)
Modified: 2018-02-10 15:25 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
accessible-event listener (498 bytes, text/plain)
2013-11-25 16:45 UTC, Joanmarie Diggs (IRC: joanie)
Details

Description Joanmarie Diggs (IRC: joanie) 2013-11-25 16:45:08 UTC
Created attachment 261465 [details]
accessible-event listener

Steps to reproduce:
1. Launch the attached accessible-event listener in a terminal
2. Launch gtk3-demo and start the Application class demo
3. Type a few characters and select them
4. Press Shift + F10 to get into the context menu

Expected results: There would be an object:state-changed event for the "cut" menu item which should have automatically become selected when the context menu appeared. There would also be a corresponding object:selection-changed event emitted by the parent menu.

Actual results: Only the deprecated focus: event is emitted.

Impact: Orca doesn't know (and doesn't present to the user) what the selected menu item is.
Comment 1 Matthias Clasen 2014-01-06 03:44:40 UTC
This is a problem of life-cycle: the menu item accessible objects simply do not exist yet when the menu item is first selected.

One way for orca to learn about the selected item would be to use the AtkSelection interface of the menu accessible.

A way to make the signals you expect happen would be to force-create the accessible objects early, e.g. in when realizing a menu item.
Comment 2 Joanmarie Diggs (IRC: joanie) 2014-01-07 18:19:37 UTC
(In reply to comment #1)
> This is a problem of life-cycle: the menu item accessible objects simply do not
> exist yet when the menu item is first selected.

The menu item exists in time to emit the focus: event. That point in the life cycle would be a good time to emit:

* object:state-changed:selected on that menu item, and/or
* object:selection:changed on the parent menu

> One way for orca to learn about the selected item would be to use the
> AtkSelection interface of the menu accessible.

True, but that requires listening for the window:activate event for the menu's parent window, verifying that the newly-active window is for a context menu, getting the window's child (the menu), then asking the menu for its selected child.

> A way to make the signals you expect happen would be to force-create the
> accessible objects early, e.g. in when realizing a menu item.

So are you already force-creating them now (i.e. for the focus: event)?
Comment 3 Matthias Clasen 2018-02-10 05:24:36 UTC
We're moving to gitlab! As part of this move, we are moving bugs to NEEDINFO if they haven't seen activity in more than a year. If this issue is still important to you and still relevant with GTK+ 3.22 or master, please reopen it and we will migrate it to gitlab.
Comment 4 Joanmarie Diggs (IRC: joanie) 2018-02-10 15:25:10 UTC
Making a dup of 711397 which is now the "object:state-changed events initially missing, but deprecated focus: event being received thus the accessible object must already exist, right?" bug.

*** This bug has been marked as a duplicate of bug 711397 ***