GNOME Bugzilla – Bug 509769
[a11y] Text for "object:text-changed:insert" event occasionally losing the first character.
Last modified: 2010-09-14 18:03:48 UTC
This bug also affect Orca bug #509423 which is blocked by this problem. It was reported against the gnome-terminal application, but I suspect it's a problem with vte, so I've filed it here. We are seeing intermittent problems where Orca is not being sent the right accessibility information from gnome-terminal. Steps to reproduce: 1. Open a gnome-terminal 2. At the prompt, type: date Occasionally we are not getting the first character of the date echoed by Orca. So we'd speak something like: SPEECH OUTPUT: 'ue Jan 15 14:01:41 PST 2008 richb@richb-laptop:~/gnome/orca/trunk$ ' instead of SPEECH OUTPUT: 'Tue Jan 15 14:01:41 PST 2008 richb@richb-laptop:~/gnome/orca/trunk$ ' I will attach an Orca debug log with more results.
Created attachment 102944 [details] Orca debug output whilst running this test. Commentary to follow.
Here's the interesting parts: The user has typed in "date" at the terminal prompt and hits Return (key press event at line 1542 in the Orca debug log file). This generates the following accessibility events: ---------> QUEUEING EVENT object:text-changed:delete ---------> QUEUEING EVENT object:text-caret-moved ---------> QUEUEING EVENT object:text-changed:insert ---------> QUEUEING EVENT object:property-change:accessible-value ---------> QUEUEING EVENT object:text-changed:delete ---------> QUEUEING EVENT object:text-caret-moved ---------> QUEUEING EVENT object:text-changed:insert ---------> QUEUEING EVENT object:property-change:accessible-value The event that's of interest to us in the second "object:text-changed:insert" event (processing starts at line 1639). I also added some debug to the Orca gnome-terminal script: $ svn diff Index: src/orca/scripts/gnome-terminal.py =================================================================== --- src/orca/scripts/gnome-terminal.py (revision 3464) +++ src/orca/scripts/gnome-terminal.py (working copy) @@ -118,6 +118,7 @@ - event: the Event """ + print "gt: onTextInserted called." # We only do special things for terminals. # if event.source.getRole() != pyatspi.ROLE_TERMINAL: @@ -135,6 +136,7 @@ self.updateBraille(event.source) text = event.any_data + print "gt: onTextInserted: text: `%s`" % text # When one does a delete in a terminal, the remainder of the # line is "inserted" instead of being shifted left. We will From this we see that the text information being inserted (passed to us via the any_data field of the event) is: gt: onTextInserted: text: `ue Jan 15 14:01:41 PST 2008 richb@richb-laptop:~/gnome/orca/trunk$ ` (see line 1771 in the debug log file). In short, we are getting the wrong information from gnome-terminal/vte.
The following steps reliably reproduce this bug: 1. With Orca running, execute vim within gnome-terminal. 2. Enter some text, then issue the gg command to return to the first line of the file. Orca neither speaks the first line nor presents it on the braille display; however, moving to the next character (i.e., the second character of the line) displays the text as expected. This problem (in all of its manifestations) makes speech and braille access to gnome-terminal unreliable.
Is anyone working on this as of now?
(In reply to comment #4) > Is anyone working on this as of now? I don't believe so. :-(
Using vte/gnome-terminal from Maverick and Orca from git master, I can no longer reproduce the reported bug. Note that the reported bug is not the same as what Jason is commenting on in comment 3. This bug is about the initial character sometimes being missing from the any_data of an object:text-changed:insert event. And that seems to be fixed. What Jason is commenting on is due to the fact that we're getting the wrong caret offset for the object:text-caret-moved event. It only seems to be happening for an offset of 0, too. I'll investigate that issue further and file a bug or work around the issue in Orca....