GNOME Bugzilla – Bug 592053
Orca sometimes presents the previous character in last line when Ctrl+End is pressed in Thunderbird
Last modified: 2009-11-09 21:35:23 UTC
Dear Developers! If I using Mozilla Thunderbird, I see two interesting problem: 1. When I edit an e-mail and press Ctrl+home key combination, the cursor jumps the last line last-1 character. If I for example write apple word, and press Ctrl+End key combination and press for example the space character, the apple word is look this: appl e So, the problem is the cursor does'nt jump after the last caracter. 2. If the last line is blank and any time I press Ctrl+End key combination, the cursor jumps prewious line last-1 character. For example, the e-mail contains two lines: apple and one blank line. If I press Ctrl+End key combination, I hear the apple word, it is not correct, because the blank line is the last line. If I press space key for example, the space key does'nt writed the last blank line, but apple word is following changed: appl e This is problem. Attila
I mistake with first problem description, the right description is following: 1. When I edit an e-mail and press Ctrl+end key combination, the cursor jumps the last line last-2 character. This is only true if the last line is not blank. If I for example write apple word, and press Ctrl+End key combination and press for example the space character, the apple word is look this: app le So, the problem is the cursor does'nt jump after the last character of last line when Ctrl+End key combination is pressed. The second problem description is good, excuse me. I test this two problems with Mozilla Thunderbird 3.0b3 and mozilla thunderbird-3.0 3.0b4pre, the described problems is present with all versions. I updated Orca with latest git master. Attila 2. If the last line is blank and any time I press Ctrl+End key combination, the cursor jumps prewious line last-1 character. For example, the e-mail contains two lines: apple and one blank line.
Presumably this is a side effect of the fix for José's hang. I'll hack in a findNextCaretInOrder which I suspect will solve the problem.
Created attachment 140960 [details] [review] proposed fix This fixes it for me. Tested in messages being composed and in received messages (including the test case for José's hanger). Attila, does this solve the issue for you?
The second problem is solved correct your patch, thank you. The first problem is partialy solved, but the problem changed after I applyed your patch: When for example writing only one line in Thunderbird message body and after this I press Home key and Ctrl+End key and append the mail editing, the cursor jumps with last-1 character. Easy test: 1. In message body, I writed apple word. 2. Pressed home key, and after this I pressed ctrl+End key combination. 3. I pressed space key, and Appended mail editing, for example I wroted the potato word. The resulted line is appl potatoe, but the correct would like line is apple potato This problem only reproduced if the message body is contains only one line. I try this test without Orca running, the resulted text is correct apple potato line. You confirm this problem? Now I look this with Thunderbird 3.0b3 version. Attila
As I indicated in the newly-filed bug 592634, it turns out that there are a number of cases in which relying upon the Gecko script's handling of caret navigation doesn't quite work as it should when composing a message. :-( Rather than continuing to make small hacks here and there in response to issues such as the ones in this bug, I propose the following: 1. Close this bug out as a dup of 592634. 2. Get users to begin testing the patch in bug 592634. 3. Commit the work in bug 592634 to master as soon as we branch. 4. Backport the fix(es) into the 2.28 branch for inclusion in 2.28.1. Thoughts?
(In reply to comment #5) > As I indicated in the newly-filed bug 592634, it turns out that there are a > number of cases in which relying upon the Gecko script's handling of caret > navigation doesn't quite work as it should when composing a message. :-( > > Rather than continuing to make small hacks here and there in response to issues > such as the ones in this bug, I propose the following: > > 1. Close this bug out as a dup of 592634. > 2. Get users to begin testing the patch in bug 592634. > 3. Commit the work in bug 592634 to master as soon as we branch. > 4. Backport the fix(es) into the 2.28 branch for inclusion in 2.28.1. > > Thoughts? Sounds like a good plan. I hope to branch on Monday or Tuesday.
Thanks Will. Marking this as a dup of 592634. Attila, if you could please start testing the patch attached to that bug in both Firefox and Thunderbird, that would be great. *** This bug has been marked as a duplicate of bug 592634 ***