GNOME Bugzilla – Bug 535183
Word navigation is inconsistent in Thunderbird and Firefox
Last modified: 2009-03-10 00:05:32 UTC
Please describe the problem: When I am editing a message and Orca is controlling the carat, word navigation is not consistent. Some of the time, when navigating by word using control-right arrow and control-left arrow, the carat behaves like a Windows application, with the carat arriving at the beginning of the word, whether movement was in either direction. At other times, movement is consistent with Orca, where the carat moves beyond the word being spoken. In this case, if you are moving forward through the document, the carat rests just after the last letter of the word spoken. If you are moving backwards through the document, the carat rests in front of the first letter of the word that was spoken. Steps to reproduce: 1. Within Thunderbird, open a new message for writing. 2. Write enough text, a couple of paragraphs,so that you can move around by word navigation without running into the start or end of the text. 3. Navigate forwards and backwards through the text using control-left arrow and control-right arrow, stopping occasionally to determine the location of the carat. Actual results: The position of the carat is inconsistent. When moving forwards, the carat is sometimes in front of the spoken word and at other times behind the spoken word. Expected results: Consistent placement of the carat. To be consistent with Orca in other applications, the carat should always land just behind the word that was spoken when navigating forward by word. Does this happen every time? Inconsistent. Other information: I haven't yet figured out any pattern to the changes in where the carat rests after a move.
Created attachment 115817 [details] [review] revision 1 This patch causes us to move the caret to the end of the word rather than the beginning when moving forward. It also makes us a lot more consistent (not 100% but I'd say 95%) consistent with where Gecko's native caret navigation places the user if Orca were not being used. The other 5% are (I think) minor and edge cases that we can worry about later if we're truly bothered by them. And, finally, it switches getWordContextAtOffset() over to the use of getObjectsFromEOCs() -- which is a prerequisite to tackling the "get the braille and speech context at the same time" refactor. Pylinted and regression tested. Please test.
I'm finding some really strange behavior with this patch. To reproduce do the following: 1. Click on the attachment for this bug 2. press control+right arrow. I can't move beyond the word index. 3. arrow down several lines 4. CTRL+left arrow back to the top of the patch. Notice that all goes well. 5. repeate step two and notice the same results.
Confirmed thanks Mike. Lemme see what I can do.
Created attachment 115925 [details] [review] revision 2 <slaps forehead> That was a dumb mistake on my part. Please try this one.
Much better. thanks much
Thanks Mike. Patch is committed to trunk. Moving to pending.