GNOME Bugzilla – Bug 150858
In gnome-terminal, the deleted character reported as "space"
Last modified: 2006-11-01 22:36:08 UTC
Same Speech for Space Bar and BackSpace ... and speech should be different. Steps: 1. Bring up gnopernicus 2. enable speech and open gnome-terminal 3. Listen and verify speech is working 4. Hit <spacebar>, listen 5. Hit <Backspace> and listen .... System configurations: Gnopernicus 0.9.7 Gnome Desktop 2.7.4 Fedora Core 2
You have to enable "Say all navigation keys" option (in Preferences->Speech Preferences)in order to have <Backspace> key reported. If this option is enabled, when you hit <backspace> you will hear "backspace" then "space". The real issue is that the character being deleted is reported as "space". So, instead to report the caracter which was deleted by hitting <backspace>, gnopernicus reports "space".
To be Exact: 1. "Say all navigation keys" is and was always turned ON. 2. Bring up gnome-terminal the 1st time, hit <space bar> (it will anounce "space") 3. Hit <Backspace>, speech does not announce even "space" (like you said above), it said something like "terminal left bracket ..." . Anything BUT saying "space" ... from there on, if you hit spacebar or back space, they all say the samething "terminal left bracket ..." It should say "space" for space bar and "backspace" for backspace ... This is important feature for navigation. I believe this is same issue for "delete" keys as well.
The problem I am seeing is that sometimes when you type a character or when you delete it ("space" in this particular situation), the speech feedback is not the expected one: this character is not correctly reported (this problem is only in gnome-terminal). I can confirm this problem, but I can _not_ confirm that <Backspace> or <Del> key are not reported. If I hit these keys with 'Say all navigation keys' turned ON, they are allways reported as "backspace" or "delete" even if gnopernicus does not correctly report the character which was deleted. I am using gnopernicus 0.9.9 but I didn't see this problem in 0.9.7
Dana - Please provide Your Specific Test case as to how you go by test and verify this problem in terms of how you came up with your result. I'd like to tried your test case and see if I get the same result. I am pretty sure that you are doing something different from orginal steps. Perhaps we (together) might discover another additional problem ?
1. Launch gnopernicus with speech enabled and "Say all navigation keys" turned on 2. Launch gnome-terminal 3. Type <space> following bu 'a', 'b', 'c' 4. Gopernicus' speech outputs "space,a,b,c" 5. Hit backspace ('c' will be deleted): speech outputs "backspace", then "space" or nothing or "Terminal <current line>" (the last one is the presentation for a generic 'terminal' event). Same output when you delete backspace again ('b' will be deleted). NOTE: "backspace" is allways spoken, but the character wich was deleted not.
Dana - Your test case was little bit different from orginal test case, and it made some different. Nevertheless, the <spacebar> is still saying "terminal left bracket ...", per your test case. With that being said ... If you turn ON "say all spaces" and "Say all navigation keys", type in a Long string of char in gnome-terminal, then hit <backspace>, it will say "space", while when <spacebar> key hit it's still saying "Terminal left bracket ...
The problem is that when a character is _deleted_ in gnome-terminal (using <backspace>) we receive following events from at-spi (AT=event received from at-spi, GN=event reported by gnopernicus): AT:bfffe790p--key event:sym 65288 () mods 0 code 22 time 5873798 keystring "BackSpace" type 1 (press = 1, release = 2) GN:8296ff0p--key event:type:11, keyID:65288, modifiers:0, keystring:BackSpace => 'backspace' will be reported AT:8297910p----"object:text-caret-moved" for 823c8e0p "Terminal" role "terminal" from "GAIL" with details 17 and 0 GN:8229c10p--"object:text-caret-moved" for 8229910p "Terminal" role "terminal" AT:821f7f0p----"object:text-changed:delete" for 823c8e0p "Terminal" role "terminal" from "GAIL" with details 17 and 1 AT:8292210p----"object:text-changed:insert" for 823c8e0p "Terminal" role "terminal" from "GAIL" with details 17 and 1 GN:828c528p--"object:text-changed:insert" for 80f2c30p "Terminal" role "terminal" The problem is that we receive an "object:text-changed:delete" followed by an "object:text-changed:insert" event. In this case, gnopernicus will present the last one (insert). A character is deleted and a <space> is automatically inserted in its place, this is why gnopernicus reports "space". In order to provide a correct output (the deleted char) when a character was deleted, gnopernicus expects to receive "object:text-changed:delete" followed by "object:text-caret-moved". What we receive now is "object:text-caret-moved", "object:text-changed:delete", "object:text-changed:insert". So I believe this is not a gnopernicus bug, gnopernicus reports what it receives.
Gnopernicus cannot/should not make assumptions about the order of these events, we do not have that much control over how applications implement text deletion and insertion. It is odd however that insertion of spaces occurs when not in 'overwrite' mode in the terminal, i.e. when backspacing at the end of a line. The last 'insert' event does appear to be spurious.
*** Bug 300206 has been marked as a duplicate of this bug. ***
*** Bug 342040 has been marked as a duplicate of this bug. ***
I don't think this is gnopernicus doing wrong. The same happens with AT-SPI as is reported in one of the dups. It all goes back to how backspace is handled in terminals... Very clumsy indeed, but I'll try to look into it.
Hi Behdad. Any chance you could investigate this problem please? We have several Orca users who would love to see it fixed. Thanks!
Created attachment 75705 [details] [review] Patch to almost fix the problem Really a hack, but it almost works. The problem is that the call to emit_text_changed_delete() in vte_terminal_accessible_text_modified() in vteaccess.c is passing in a GObject* that has its snapshot_text variable already setup for the new text data. We really need to pass in the old data so that we can pass on the correct character that was deleted to the accessibility framework. The one remaining problem is that this doesn't do the right thing if you backspace over a space. I'll investigate that tomorrow.
Sorry Rich, VteAccess is all black magic to me. Good to see you are hacking it.
Created attachment 75751 [details] [review] Patch to hopefully fix the problem. The new attached patch seems to nicely fix the backspacing over a space as well. Note that in Orca I mapped vte to use the gnome-terminal script (new line at the bottom of .../src/orca/settings.py) and it seemed to do just fine. I'll add that patchlet as an attachment to bug #353422. I'd appreciate if someone could test out this patch with latest Orca. Thanks.
Thanks Rich. Waiting for someone to test and confirm efore committing.
Happily this patch is working well for me with the latest Orca from CVS head. Thanks much rich, this makes terminal much much easier to use with Orca.
Thanks Mike. Behdad, would you like to commit, or shall I?
(In reply to comment #18) > Thanks Mike. Behdad, would you like to commit, or shall I? Go ahead for HEAD and vte-0-14. Thanks.
Okay. After lunch. ;-) More in an hour or so...
Changes checked into CVS HEAD. I just tried: % cvs co -r vte-0-14 vte Enter passphrase for key '/export/home/richb/.ssh/id_rsa': cvs [server aborted]: no such tag vte-0-14 What's the tag for this release?
(In reply to comment #21) > Changes checked into CVS HEAD. I just tried: > > % cvs co -r vte-0-14 vte > Enter passphrase for key '/export/home/richb/.ssh/id_rsa': > cvs [server aborted]: no such tag vte-0-14 > > What's the tag for this release? Heh, we've not branched yet it seems. The better :). Thanks Rich.