GNOME Bugzilla – Bug 659235
If a dialog has a focused GTK.Entry control, Orca doesn't speak the deleted character
Last modified: 2014-07-22 17:54:01 UTC
Created attachment 196713 [details] This debug.out file shows what happening when I tested run application dialog the Backspace key press happening speech problem. Dear Developers, Because following problem is possible not only bug 659122 related unicode encode or decode problem for hungarian locale, I opened following problem related a separated bug: If a dialog containing a Gtk.Entri control, and this control have typed text, Orca doesn't spokening the deleted character if the user press Backspace key. I reproduced this problem for example with Gedit file save dialog text entry, or the run application dialog. Reproducation steps: 1. Press for example Alt+F2 key, and type some text with run application edit box. 2. Try press Backspace key. If you do where am I operation, Orca wonderful spokening the selected text. But after Backspace key press Orca doesn't spokening the deleted character. In braille display wonderful presenting the changed text, if you wrote for example the apple text, you will be see first Backspace key press with appl text, second Backspace key press with app text, etc. In the debug.out file seeing the speech output string is empty if the Backspace key press happened. I attached the debug.out file, hopefuly this is not a GTK3 specific issue. Attila
Well, the problem here seems to be that we're not getting the right information from the object:text-changed:delete event. The event's any_data happens to be the character at the caret -- and if you're backspacing from the end, the caret is always at the end. As for why this problem is not in braille: In braille we just display the text that is on the screen and, much like editing text visually, the idea is that you know what was there before, and you know what is there now. In other words, it's only in speech where we rely upon the event's any_data. Having said all of that: 1. This is not a "critical" bug by any stretch of the imagination. Bugzilla's definition of "critical" is: "Crashes, causes loss of data, or is a severe memory leak". This bug on the other hand is merely a pain in the butt. 2. Recently new text-related signals were added. I need to look up what they are. But if we are getting the correct information perhaps we can start listening to those instead.
So more details as I'm slowly wrapping my head around this: * Looking at bug 638377, the new events seem to be: - text-insert - text-remove - text-update * I created a stand-alone listener (i.e. not in Orca) to listen for all object events and just printed out anything that had the word 'text' in its name. But the new events are not showing up; just the old ones. * In IRC Trev stated, "afaik mgorse or fer or someone said the bridge or bus maps them to text-changed before passing to pyatspi." That would explain my finding above. So apparently I cannot listen for the new events instead of the old ones. * I was momentarily tricked into thinking that the problem was in whatever maps them to text-changed because Firefox 6 and Gtk+ 3 exhibit the same behavior. But Firefox 7 does the right thing. Thus this seems to be a Gtk+ 3 bug that needs to be fixed in Gtk+ 3. I'll build Gtk+ from master and if the issue persists, file a new bug.
Bug 659445 filed.
The Gtk+ bugs have been fixed. Are you still seeing this bug in GNOME 3.6?
(In reply to comment #4) > The Gtk+ bugs have been fixed. Are you still seeing this bug in GNOME 3.6? Hi Hammer, I am closing this bug report as no updated information has been provided. Please feel free to reopen this bug if you can provide the information that was asked for in a previous comment.