GNOME Bugzilla – Bug 657960
Accessibility: reading text while scrolling off by one character
Last modified: 2014-08-03 11:27:43 UTC
When the text scrolls, the first character gets lost when read by orca. For example, I might hear "est" instead of "test". To reproduce, you can run: seq 1 100 #To fill up the screen sleep 1;echo test The sleep 1 is needed, because if the first character is the newline echoed from pressing enter, orca won't notice if it gets lost; it's just whitespace. In the debug log, text-changed::insert will say it's inserting est, e.g.: Accessibility peer emitting `text-changed::insert' (84, 6) (84, 6). Inserted text was `est $ '. Where $ is my prompt. I've been going through vte_terminal_accessible_text_scrolled, and changing the strlen call to this seems to make it work: i = strlen(priv->snapshot_text->str + i) - 1; I don't really understand the code, so am unsure what else that will break, or if this is indeed the right solution. I've tested with 0.28 on Archlinux, and gnome-terminal in ubuntu-based distros (which uses libvte) also has this issue.
Confirmed with current master. At the code you mention: i = strlen(priv->snapshot_text->str + i); the data at priv->snapshot_text->str ends with two \n characters, the second of which silently gets overwritten by 't' (the first letter of "test"). Actually, priv->snapshot_text->str always seems to contain a \n after every row, e.g. with an empty 80x24 screen its contents is 24 \n characters. To compensate for this newly appearing (or disappearing) \n character when scrolling, an offset by "howmuch" needs to be made somewhere... somewhere around the line you pointed to.
Created attachment 282406 [details] [review] Fix Here's a fix, it's quite similar to Tyler's original patch. We're always off by exactly 1, even if scrolling by multiple lines. This is because snapshot_text always contains a trailing newline, and insertion happens before this newline.