GNOME Bugzilla – Bug 571062
object:property-change:accessible-value events not emitted for progress bars
Last modified: 2018-04-15 00:26:57 UTC
To reproduce: 1) Run the to-be-attached test case in an xterm 2) open gnome-terminal then: cd ~/Desktop dd if=/dev/zero of=zeros.null bs=16M count=60 3) Open your Desktop in a nautilus window. Select zeros.null. Press ctrl+c, followed by ctrl+v to copy it. 4) The copying window will appear, and you will see a progress bar providing the status of the copy operation. In the xterm window, you will not see accessible-value events emitted for the progress bar when you should. NOW.... Try the same steps above, but while the copy operation is performing, launch accerciser and drill down to the nautilus progress bar. You will see that events start getting emitted. I don't know for sure what's going on here, but it seems as though the ATK peer for the progress bar might not get created until one drills down the hierarchy from the top.
Confirm. I think this is because the accessibility object of progress bar is not created. Is this a gail bug? I think ref the object in AT can fix it.
(In reply to comment #1) > Confirm. I think this is because the accessibility object of progress bar is > not created. Is this a gail bug? I think ref the object in AT can fix it. I think it might be a gail bug. In order for Orca to start getting the events, I believe Orca needs to force the accessible peer to be created by looking downwards in the hierarchy. This shouldn't be the case -- if the object is on the screen, the peer should automatically be created and should be emitting events. Thanks so much for looking at this, Li!
Li - do you think this might be an issue with something in the GTK+ side not giving the proper events to let GAIL know the progress bar has been created/added?
Yes, the problem is the progress bar is added by gtk_box_pack_start and gail doesn't notice that. Should listen to "child-notify" signals from GtkBox.
OK... The problem is that nautilus uses gtk_box_pack_start to add children to top level window and then show the window. gail emits "children-changed::add" when the window is showed. At this time, the accessible peer of the window is created. But the accessible peer of GtkBox get no chance to be created. (normally the accessible peer is created when there is children-changed:add signal.) I am confused that this should be a bug for every application. e.g. 1. start accerciser and listen for "children-changed::add" signal 2. start gedit (accerciser find a "children-changed::add" signal for gedit) 3. press "New" button to create a document. (no "children-changed::add" for the new document) But if we drill down to the page tab list in accesciser, we can get "children-changed::add" Does Orca do something special to create accessible objects? e.g. listen to the mouse event and ref the accessible object?
Strange. There might be some strange side effect happening somewhere that I don't expect, but I believe Orca is just listening for events. I wonder if the fact that the object gets focus helps GAIL realize it exists?
ping.
ping
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.
As announced a while ago, we are migrating to gitlab, and bugs that haven't seen activity in the last year or so will be not be migrated, but closed out in bugzilla. If this bug is still relevant to you, you can open a new issue describing the symptoms and how to reproduce it with gtk 3.22.x or master in gitlab: https://gitlab.gnome.org/GNOME/gtk/issues/new