GNOME Bugzilla – Bug 711397
object:state-changed event and/or state missing when certain Gtk+ widgets gain focus/selection
Last modified: 2018-05-02 15:51:52 UTC
Created attachment 258916 [details] Event listener Steps to reproduce: 1. Launch the attached accessible event listener in a terminal 2. Open the gtk3-demo Combo boxes demo 3. Press Tab to move amongst all the widgets Expected results: Each time a GtkComboBox gains focus, an object:state-changed:focused event would be received. Actual results: The first time each GtkComboBox gains focus, no object:state-changed:focused event is received. These events are received all subsequent times the widgets are Tabbed to. Related: The first time each GtkComboBox gains focus, a focus: event is emitted. But since that event is deprecated....
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 on attachment 258916 [details] Event listener >#!/usr/bin/python > >import pyatspi3 > >def listener(e): > if e.detail1: > print(e) > >pyatspi.Registry.registerEventListener(listener, "object:state-changed:focused") >pyatspi.Registry.start()
Comment on attachment 258916 [details] Event listener >#!/usr/bin/python3 > >import pyatspi > >def listener(e): > if e.detail1: > print(e) > >pyatspi.Registry.registerEventListener(listener, "object:state-changed:focused") >pyatspi.Registry.start()
(Ignore comment2. I need more coffee.) In more recent environments, but where python2 is still the default, the original script may fail as a result of the python bindings not being found. They should be present for python3, however. And, yes, this bug still persists. Given the move to gitlab, and the fact that there are multiple bugs where $WIDGET fails to emit object:state-changed:focused even initially, it probably makes sense to have just one bug for the broader problem and migrate that one over. Aside: A non-trivial percentage of Orca's Gtk+ script is to work around this issue. Thus if one sees hacking around toolkit bugs as a shortcoming of Orca, fixing these missing events would be a significant step in fixing that shortcoming. :)
*** Bug 748311 has been marked as a duplicate of this bug. ***
*** Bug 715179 has been marked as a duplicate of this bug. ***
*** Bug 720989 has been marked as a duplicate of this bug. ***
*** Bug 758298 has been marked as a duplicate of this bug. ***
*** Bug 654410 has been marked as a duplicate of this bug. ***
*** Bug 715176 has been marked as a duplicate of this bug. ***
*** Bug 758189 has been marked as a duplicate of this bug. ***
*** Bug 720987 has been marked as a duplicate of this bug. ***
*** Bug 654405 has been marked as a duplicate of this bug. ***
*** Bug 560832 has been marked as a duplicate of this bug. ***
*** Bug 560826 has been marked as a duplicate of this bug. ***
*** Bug 580460 has been marked as a duplicate of this bug. ***
*** Bug 580452 has been marked as a duplicate of this bug. ***
In addition to the above duplicates, Orca used to have role-specific hacks for quite a few Gtk+ widgets to accept the deprecated focus: events. These had been added on a per-widget/role basis each time an Orca user would complain a newly-focused widget was not being spoken. After enough of these reports, I wound up removing all that and treating focus: as if it hadn't been deprecated for Gtk+. Long way of saying: We should assume that all GtkWidget instances suffer from this problem.
-- GitLab Migration Automatic Message -- This bug has been migrated to GNOME's GitLab instance and has been closed from further activity. You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.gnome.org/GNOME/gtk/issues/454.