GNOME Bugzilla – Bug 547496
Cursor navigation does not start from insertion carat location in Thunderbird Write window
Last modified: 2008-09-11 18:20:32 UTC
Please describe the problem: When typing in a new email message in Thunderbird, the starting position when using cursor navigation is not located at the insertion carat. Often, but not always, cursor navigation begins from the last location reached by cursor navigation. the example below describes this problem in terms of the up and down arrow keys, but the same is true for left and right arrow keys as well. Steps to reproduce: 1. Start Orca. 2. Start Thunderbird. 3. Open a new message for writing. 4. Type a paragraph of text. 5. Press the up arrow key to review the text recently typed. (I get no feedback) 6. Press the down arrow key repeatedly to hear the contents of the paragraph from the second line down. 7. Move to the end of the first paragraph, insert a blank line and then type a second paragraph of text below the first. 8. Use the cursor keys to establish your position in the text. Actual results: After writing the first paragraph, pressing the up arrow results in no feedback while pressing the down arrow reads the text from the second line to the end of the paragraph. After typing the second paragraph, pressing the up arrow places the cursor in the blank line and repeatedly pressing the down arrow key will read the contents of the paragraph. Expected results: After typing the first paragraph, pressing the up arrow should read the second to the last line of the paragraph, and a following down arrow will read the final line of the paragraph. In fact, cursor navigation should always start from the location of the insertion carat. Does this happen every time? Yes. Other information: Debug log to follow.
Hi David, what format are you using to compose your messages? I just want to make sure I'm testing the exact same situation you are.
Created attachment 116456 [details] debug log Actions taken during this log: New email mesage is created. Addressee and Subject are filled in. A paragraph of text is typed, then cursor navigation keys are used to establish the position of the cursor in the text. Cursor position is moved to the end of the message, a blank line is inserted, followed by another paragraph of text. Cursor keys are used to establish the location of the cursor.
(In reply to comment #1) > Hi David, what format are you using to compose your messages? I just want to > make sure I'm testing the exact same situation you are. > I'm going to have to plead ignorance here. I have made no changes (to the best of my knowledge), so should be using the default behavior of Thunderbird. I just spent some time going through the Preferences dialog for Thunderbird (just so there is no confusion, not the orca Thunderbird Preferences :-), and I can't find where the format is explicitly set. If you let me know where the format is set, I'll take a look and let you know. Thanks!
(In reply to comment #0) I also experience this bug. Someone suggested turning on Gecko mode (Ins+F12) which works; however, this results in the inability to read emails. > Please describe the problem: > When typing in a new email message in Thunderbird, the starting position when > using cursor navigation is not located at the insertion carat. Often, but not > always, cursor navigation begins from the last location reached by cursor > navigation. the example below describes this problem in terms of the up and > down arrow keys, but the same is true for left and right arrow keys as well. > > Steps to reproduce: > 1. Start Orca. > 2. Start Thunderbird. > 3. Open a new message for writing. > 4. Type a paragraph of text. > 5. Press the up arrow key to review the text recently typed. (I get no > feedback) > 6. Press the down arrow key repeatedly to hear the contents of the paragraph > from the second line down. > 7. Move to the end of the first paragraph, insert a blank line and then type a > second paragraph of text below the first. > 8. Use the cursor keys to establish your position in the text. > > > Actual results: > After writing the first paragraph, pressing the up arrow results in no feedback > while pressing the down arrow reads the text from the second line to the end of > the paragraph. After typing the second paragraph, pressing the up arrow places > the cursor in the blank line and repeatedly pressing the down arrow key will > read the contents of the paragraph. > > Expected results: > After typing the first paragraph, pressing the up arrow should read the second > to the last line of the paragraph, and a following down arrow will read the > final line of the paragraph. In fact, cursor navigation should always start > from the location of the insertion carat. > > Does this happen every time? > Yes. > > Other information: > Debug log to follow. >
(In reply to comment #4) > (In reply to comment #0) > I also experience this bug. Someone suggested turning on Gecko mode (Ins+F12) > which works; however, this results in the inability to read emails. Robert, I'll send you an email to describe what I know about using gecko to control the carat. It's better discussed off this page.
As an aside, I'm aware of some of the issues about Orca not always speaking the contents of line if Gecko is controlling the caret. It's on the list of things I'm working on. Just need the time fairy to show up and give me some 48-hour-long days. <smile>
Reassigning to me.
Created attachment 118388 [details] [review] revision 1 Please test.
Joanie, Sorry, but I won't be able to test until this weekend at best. My luck with the distribution upgrades is universally bad. I tried using update-manager to get my gutsy machine to be at least hardy (I couldn't get intltools trunk to be recognized in gutsy) and the upgrade hung. So, I'm trying to get someone to help me install Intrepid on my home work machine this weekend. I'm hoping it's close enough to behave reasonably well... famous last words. ;-) Once I have a working gnome desktop, I'll test the patch. Thanks!
For me this patch seems to work well.
Thanks Mike. The patch for bug 535188 includes this fix, and I just committed that patch. So I'm obsoleting the version of the patch associated with this bug and closing as FIXED.