GNOME Bugzilla – Bug 356515
[a11y] Orca unable to read items in Evolution "Select a Folder" dialog after partial folder name is given.
Last modified: 2007-03-10 22:54:09 UTC
See comment #3 of bug #352086 http://bugzilla.gnome.org/show_bug.cgi?id=352086#c3 for more details. I will attach a small standalone Python script that reproduces the problem. To run it, type 'python bug_352086.py'. To reproduce this bug, follow these steps: 1) Run this module in an xterm using 'python bug_352086.py' 2) Run Evolution in Mail View. 3) Select a message in your inbox to move 4) Press Control Shift V 5) Arrow up and down in the list of folders (items should be spoken). 6) Type the first letter of a folder name. A small text area window will appear. 7) Dismiss this window with the Esc key. 8) Arrow up and down again in the list of folders (items are no longer spoken). Initially when you arrow up and down, each arrow movement is causing an event such as the following to be generated: OBJECT EVENT: object:active-descendant-changed detail=(5,0) app.name='evolution-2.6' name='Mail Folder Tree' role='tree table' state='ENABLED FOCUSABLE FOCUSED SENSITIVE SHOWING VISIBLE MANAGES_DESCENDANTS' Notice that one of the states is FOCUSED. After you dismiss the text area with the Esc key and arrow up and down, each arrow movement is causing an event such as the following to be generated: OBJECT EVENT: object:active-descendant-changed detail=(7,0) app.name='evolution-2.6' name='Mail Folder Tree' role='tree table' state='ENABLED FOCUSABLE SENSITIVE SHOWING VISIBLE MANAGES_DESCENDANTS' Notice that it no longer has a FOCUSED state. That's the problem. Without the FOCUSED state, Orca will not speak this change.
Created attachment 72972 [details] Standalone Python script that reproduces this problem.
Created attachment 72973 [details] Debug output generated when running "python bug_352086.py"
Note also that Joanie is seeing this problem with Evolution 2.8 on Ubuntu Edgy.
Hi. Any update on this bug? Thanks.
The bug happens in all gtktreeview, not only Evolution. I am investigating it.
Created attachment 75710 [details] [review] patch to fix this bug
*** Bug 351766 has been marked as a duplicate of this bug. ***
(I am not so sure if the patch is right at this point, I hope to research this more in depth soon)
Patch looks right to me. gtk is just missing firing a focus event when the search entry popup is destroyed and keyboard input focus returns to the tree view.
To me the patch appears to send this focus event as soon as the search entry popup is created. And the current code which is taking care of hiding the search popup does actually send a focus change.
Doh. You're right. It does look like a focus out event is being fired when the dialog is hidden in: gtk_tree_view_search_dialog_hide using the call: send_focus_change (GTK_WIDGET (tree_view->priv->search_entry), FALSE); But does this imply a focus in event is fired for the tree again? Or is another explicit call needed to indicate focus is back on the tree? That is, does the method need a: send_focus_change (tree_view, TRUE);
I guess Peter is right here. It is a bit odd that send_focus_change sends unpaired focus events. If you look at the use of do_focus_change() in gtkwindow.c (which is what send_focus_change was copied from), it is called in pairs.
Fixed on gtk-2-10 and trunk.
[The fix has been reverted from gtk-2-10 for the GTK+ 2.10.10, since the fix broke the general focus handling in GtkTreeView. I will be working on a different fix, but that won't make 2.10.10...].
Okay. Thanks. Good to know. Shouldn't you reopen the bug?
Found the problem causing the breakage; gtk_tree_view_focus_out() called gtk_tree_view_search_dialog_hide(), which caused a focus-in event to be sent to the tree view again (even though the search dialog was not actually visible) so things messed up. gtk_tree_view_search_dialog_hide() now only hides the dialog and sends those focus events when it is currently visible. Trunk and gtk-2-10 both have fixes; went into gtk-2-10 in time for GTK+ 2.10.10.