GNOME Bugzilla – Bug 720989
Accessible state-changed events missing when giving keyboard focus back to parent menu
Last modified: 2018-02-10 15:27:12 UTC
Created attachment 264819 [details] accessible-event listener Steps to reproduce: 1. Open the attached accessible-event listener in a terminal 2. Launch gtk3-demo's Application Class demo 3. Get into the Preferences menu 4. Choose the color submenu 5. Press Right to select the first item in the color submenu 6. Press Left to move keyboard focus out of the color submenu Expected results: At step 6, some state-changed event would be emitted to inform ATs that "Color" was reselected (i.e. that Up/Down will now move you in the Preferences menu). Actual results: At step 6, there is no state-changed event to inform ATs that "Color" was reselected. Notes: * Currently there is a focus: event to inform ATs that "Color" was reselected, but this event type has been deprecated so Orca will need some other notification that what has keyboard focus has changed. * Because we are seeing object:state-changed:selected on menus and menu items (and not object:state-changed:focused), I think it would be helpful to have this event at step 6 as well. Yes, even though technically the Color menu never became unselected. ;) Failing that, object:state-changed:focused should be fine.
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.
*** This bug has been marked as a duplicate of bug 711397 ***