GNOME Bugzilla – Bug 475674
[a11y] state-changed:focused events missing for document when go to line is used
Last modified: 2008-01-08 17:38:22 UTC
Steps to reproduce: 1. Get Accerciser (http://live.gnome.org/Accerciser) 2. Launch Gedit, open a document. 3. In Accerciser, select Gedit and drill down to the document object. In Accerciser's Event Monitor, select the "Selected accessible" radio button and check the state-changed checkbox (under object). 4. Return focus to the document. Press Control I for go to line, type a line number and press Enter. Rinse and repeat a few times. Expected results: Every time step 4 was executed, a pair of events would be present looking something like this: object:state-changed:focused(0, 0, None) source: [text | ] application: [application | gedit] object:state-changed:focused(1, 0, None) source: [text | ] application: [application | gedit] Actual results: These events are not present. Other observations: Also after step 4, the document lacks STATE_FOCUSED. It seems that it's giving up focus to the go to line entry (we get all the expected a11y events for that object) and never reclaiming it. Because of this, assistive technologies such as Orca are not aware of the currently-focused object and stop providing access to the document content after go to line is used. Thanks in advance!!
Hi everybody!! Gedit is an application easy to use, and very important for many people. It has a really accessible interface and also understandable, so i think that bugs like this one should be fixed 'cause for developers the count line tool is one of the most important when you have a really long piece of code. I needed it today and gedit presented the same bug, so i had to change focus through the different windows to get gedit speaking again. I hope you fix this bug and make things easier for everyone. :-D Thanks. Greetings.
Just a quick ping to see if anyone might be able to look at this bug.
well, after the line number is entered focus is returned to the textview... I am bot really sure what else should we do, if you guys have any suggestions I'd be happy to hear it.
(In reply to comment #3) > well, after the line number is entered focus is returned to the textview... I > am bot really sure what else should we do, if you guys have any suggestions I'd > be happy to hear it. > Hi Paolo: Thanks for the response! Do you know where in the gedit code this is happening? We could take a look at it and see if anything strange is going on. If not, this could potentially be an atk or gail bug.
the code is in gedit-view.c and starts at the function start_interactive_goto_line. From there the "go to line" code is shared with the "incremental search" code since both pop up an entry and scroll the text view in a find-as-you-type manner.
(In reply to comment #5) > the code is in gedit-view.c and starts at the function > start_interactive_goto_line. From there the "go to line" code is shared with > the "incremental search" code since both pop up an entry and scroll the text > view in a find-as-you-type manner. > It seems as though somewhere around or after gedit-view.c:hide_search_window we might want to force a grab_focus on the multiline text area that's the child of the active page tab. Any idea how I might get a handle to that from inside gedit-view.c?
the GeditView itself is a subclass of GtkTextView, so it is the widget that must grab the focus
(In reply to comment #7) > the GeditView itself is a subclass of GtkTextView, so it is the widget that > must grab the focus > Thanks Paolo! I tried doing a gtk_widget_grab_focus on the view in gedit-view.c:hide_search_window, but I think that's the wrong view. The thing I'm trying to find is the multiline text area that's the child of the active page tab. Any idea how I might get a handle to that from inside gedit-view.c?
No, I am pretty sure it's the correct view... there must be something else going wrong: note that in hide_search_window we already call send_focus_change which should move the focus to the view...
(In reply to comment #9) I tried adding this call in hide_search_window, but it doesn't seem to generate any focus events for us: gtk_widget_grab_focus (view); > going wrong: note that in hide_search_window we already call send_focus_change > which should move the focus to the view... The call to send_focus_change looks like this: send_focus_change (GTK_WIDGET (view->priv->search_entry), FALSE); It is merely saying that the search_entry no longer has focus, but doesn't explicitly give anything else focus. This gives me an idea, though, and I think this problem can be fixed with one line of code. Look for a patch soon.
Created attachment 102393 [details] [review] Patch to force focus on the view This patch makes sure a focus event is issued for the view when the search window goes away. Seems to work nicely.
> window goes away. Seems to work nicely. Confirmed: Now Orca automatically does the right thing (speaking the line where the caret has moved). Thanks Will!!
Great! please commit
Committed and closing as FIXED. Thanks so much for your help and trust!