GNOME Bugzilla – Bug 387556
Arrowing past last character at end of line in Orca results in no speech
Last modified: 2009-05-25 15:25:16 UTC
(From the gnome-accessibility list): ...when we move char by char and we go to the end-of-line i.e. after the last char, Orca says the last character of the line, as Jaws for Windows says "Blank" or "Empty", which is better I think. Example: Suppose a line "Hello World!" in OOO writer. If we do a right arrow until the end of the line Orca will say H e l l o "blank" W o r l d ! ! (it says the exclaim two times). It would be better to say W o r ld ! "empty" with maybe an extra "End of line" sentence if Verbose speaking is selected.
Created attachment 78634 [details] [review] possible solution It seems that OOo Writer is returning the last character when we're at the end of the line. In all apps, if we're at the end of the line, we shouldn't be getting a character. Therefore, what about doing an explicit check for this condition and setting the character to "\n" should it be true??
This seems reasonable to me, but as it's a change that will potentially affect all applications (not just OOo Writer), I'd like Will to comment first before we commit this.
I'm not trying to pass the buck here, but Mike really needs to comment on this one from a usability standpoint. The general problem is this: there are times where the caret can end up at the end of a line, such as arrowing there by character or word. When I arrow character-by-character going from left to right across the line, Orca sometimes doesn't say anything when I reach the end of the line. For example, type these two lines in gedit and OOo: this is a test this is another Right arrow from left to right across the word "test". You'll hear each character to the right of the caret. But...when you arrow across the last 't' of test, but don't move to the beginning of the next line, orca says nothing. As we see with this bug (bug 387556), if you do the same thing in oowriter, you will hear the 't' spoken again, which is inconsistent and confusing. The patch supplied by Joanie seems to keep the gedit behavior the same and makes the OOo behavior match that of gedit. The question I have, however, is if silence is golden in this case. In phone conversations with Mike, he indicates that he thinks it is OK - you will hear the 'newline' announced when you move to the beginning of the next line.
Well, I'm not Mike but.... My goal was to be consistent with gedit. That said, personally, I'd rather hear something when I arrow to that character. Hearing nothing is just as confusing as hearing a character that isn't there.... But that's just me. :-)
My opinion on this one is that hearing nothing isn't that big a thing as the next movement will tell you generally that you have moved to a new line. A compromise we might be able to make would be to remove the current new-line speaking functionality and replace it with a feature that speaks end of line after speaking the last character, word or what ever. The only way I would really be OK with this is if we can reliably determine when we are at the end of a line in all applications. If we simply add end of line functionality to what we already have it will be too verbose.
I'm cool with it indicating the end of the line, and not speaking "new line" at the beginning of the new line. As it is currently, arrowing right the first time causes nothing to be spoken; arrowing right the second time causes two things to be spoken (newline followed by the current character). Making the change Mike suggests would make it clear where you were with *each* press of right arrow.
I'm OK with either Joanie's or Mike's opinion here, though I think saying "end of line" might be better for a variety of reasons: it definitely lets you know where you are, and the code to do this might be a bit cleaner (the newline code currently jumps through hoops to do its thing). Some more thought has to be given to the user experience, though, especially what will happen when you arrow through several blank lines in a row. The main thing, however, is to make things consistent. I propose this: check in Joanie's patch since it accomplishes the consistency part. Then, retitle this as an RFE to say "end of line" if that is what we think the better user experience is.
Thanks! I checked the patch in since it makes things more consistent across the board. I'm also retitling this to "Arrowing past last character at end of line in Orca results in no speech" and making it an RFE.
First coarse pass at GNOME 2.24 planning.
With the recent changes to how text selection is handled (see bug #517048), there were still some newline related situations which weren't be spoken correctly. These have been moved over from that bug to this bug, so they can be properly handled as a part of this fix. Here's how to recreate them. Note that I tried this with the OOo 3.0 (beta) build that I had available (OOo_3.0.0_080514_unxlngi6_install) and the problems exist there too: ------------------------------------------------------------------------ Type the following in a new OOo Writer document (excluding the lines that say "top of doc" and "end of doc"): ---------------top of doc-------------- This is a test. So is this. ---------------end of doc-------------- Issues: 1. Select character by character. Once you've selected the period, press Shift+Right again (selecting just the newline). CORRECT: newline -- or newline selected (to be spec'ed) CURRENT: selected ------------------------------------------------------------------------ 2. Having done the above, press Shift+Left Arrow to unselect the newline. CORRECT: newline -- or newline unselected (to be spec'ed) CURRENT: unselected ------------------------------------------------------------------------ 3. Unselect everything. Then select word by word from the beginning through "test" (i.e. "test" is selected but the "." is not) Continue to select forward by word to select the period. Continue to select forward by word to select the newline/ paragraph boundary. CORRECT: newline -- or newline selected (to be spec'ed) CURRENT: <silence> ------------------------------------------------------------------------ 4. Move to the end of the document. Press Control+Shift+Left to select the period. Then press it again to select "this". Continue selecting backwards by word. After "So is this." is selected, press Control+Shift+Left again. CORRECT: newline -- or newline selected (to be spec'ed) CURRENT: newline ------------------------------------------------------------------------
Here's another test case from Will that we need to make sure is fixed: Type some text in gedit. A couple lines, like "I really think.<newline>This is the newline bug." Press Ctrl+a. All the text is selected. The caret is moved to the beginning of the text. Press the left arrow. The caret isn't moved. The selection is cleared.
Sorry for the spam. Targeting to get it more noticeable on my radar in the hopes of actually working on it for the upcoming major release. ;-)
Created attachment 128943 [details] [review] speak newline at the end of the line, clean up some selection issues NOT regression tested yet. Lots of tests to run....
Created attachment 128953 [details] [review] same code, a few updated gtk-demo tests Will, ran the OOo Writer tests and the gtk-demo tests so far. Going to run the Firefox tests now.
All (2 hours and 30 minutes worth) of the firefox tests passed with 1 exception: We sometimes speak the selected state of text when using the Find toolbar. Note that we still present everything else (i.e. Find still works as expected), we just tack on the additional word for state at the end. I should be able to target that case directly. But it's nearly 4 AM, so first I will nap. :-)
Created attachment 128985 [details] [review] add targeted fix for aforementioned Gecko issue This patch adds an onTextSelectionChanged method to the Gecko script which checks to see if we (locusOfFocus) are not in document content, but the accessible issuing the object:text-selection-changed event is. In that case we return silently (i.e. without presenting selection state for the event). In all other cases, we pass things on to the default method for handling.
Please test. This would be a good improvement for 2.26. Thanks!
Created attachment 129625 [details] [review] Hopefully a motivator for lots of good testing. What did you do today Joanie? I'm glad you asked. I started looking (again) at the issue of text selection in Firefox. I need the patch for this bug in place for what I'm doing. While the whole issue of text selection in Firefox is rather complicated and can fall apart when trying to select across non-text objects, this patch now has very rudimentary support for, yes, text selection in Firefox. (Note the rudimentary bit.) Wouldn't it be great to at least have some initial support in this area for 2.26? I think so. :-) Beat on this patch!!!! Thank you. That is all. ;-)
I chatted with Will about all of this. I'm of the opinion that the patch attached to comment #16 is a major improvement over what we currently have. What I attached in comment #18 is, admittedly, a start on the work bug 412100. Sorry Will! So.... The Gecko selection patch is obsolete. The patch attached to comment #16 has been committed to trunk with the following change: - mods = orca_state.lastInputEvent.modifiers + try: + mods = orca_state.lastInputEvent.modifiers + eventString = orca_state.lastInputEvent.event_string + except: + mods = 0 <-------- (I had it as None before, which was dumb) + eventString = "" + I'll work on the Gecko stuff separately. Closing this bug as FIXED.
I think this patch may have introduced a regression. :-( 1) Write five line with oowriter application, pressing Return at the end of each line: Will Mike Attila Monicca Mathew 2) Pessss Ctrl+a key to select all the text. You will hear "Selected. Selected. Selected. Selected. Selected." (One "Selected" for each line of text). Prior to this patch, you would only hear "Selected" being spoken once.
Sorry! :-( I've opened bug 583811 for the issue you report. Re-closing this one.