GNOME Bugzilla – Bug 381391
Flat review does not obtain correct word and char indices at the end of the file
Last modified: 2006-12-05 22:10:36 UTC
Please describe the problem: When one switches to flat review from focus tracking mode, Orca should ideally set the word index to the word at the caret and the character index to the character at the caret. If this is not possible, Orca should strive to minimize the distance flat review moves away from the character at the caret. This is what occurs UNLESS the caret is at the end of the file. Under those circumstances, Orca seems to correctly identify the current line and zone indices, but sets the word and char indices to 0. Steps to reproduce: 1. Launch Orca 2. Launch an editor (I can reproduce this in both Gedit and OOo Writer) 3. Type "This is a test." WITHOUT a final space or carriage return 4. Press left arrow once to move the caret between the final "t" and the period. 5. Press KP_5 to review the current word. 6. Press right arrow once to move the caret between the period and the end of the file 7. Press KP_5 to review the current word. Actual results: After step 5, the word under flat review is "test." (as expected). However, after step 7, the word under flat review is "This" Expected results: Given that you cannot flat review to the EOF character, Orca should do one of two things: 1. Announce/display in braille the fact that the current location is not reviewable 2. Minimize the amount of movement away from the present location. In other words, rather than reviewing the beginning of the current zone, review the word that is closest to the present location (in this case, the previous word, "Test.") Does this happen every time? Yes Other information: This was discovered as part of the implementation of a flat review find. (See http://bugzilla.gnome.org/show_bug.cgi?id=354463). I'm making progress towards a proposed solution. In the meantime, I'm filing here to separate this from Find, as they are independent issues.
Created attachment 77604 [details] [review] Patch to hopefully solve the problem I spoke with Mike about this. He indicated that the desired behavior is to treat the character immediately before the caret as the current one. This patch implements that functionality.
I took a look and I came across a small problem: you will end up hearing the last character on the line twice when you: 1) Position the caret at the end of the document 2) Press KP_2 to review the current character (it will be the last character) 3) Press KP_1 to move to and review the previous character (it will still be the last character) I'm going to hack a little bit to see if I can resolve this.
Created attachment 77755 [details] [review] Patch to hopefully resolve both problems. :-) Here's a patch that is a little simpler (it isolates the logic to the intialization of the flat review context) and seems to resolve both the original problem and the one in the patch. Joanie - can you please give it a try (and thanks tons for your investigation on this)?
Oh sheesh.... Looking at your patch, I'm feeling rather silly for not doing it the way you did. Yes, your patch does indeed solve both problems. Thanks for looking over my patch AND for fixing it and the problem. :-)
Thanks! Committed the patch and closing this bug.