This bugs the heck out of me. You're typing something into a window for usenet or email [in mozilla mail] an each time you scroll near the end of the window it jumps to the top. That and adding text exactly one line below a paragraph is hard [it adds another CR before]. Tom

Looks like it could be bug 46347?

Reporter, Are you talking about moving the insertion point with the keyborad, or using the scrollbar with the mouse? I remember seeing something about using the keyboard to move the insertion point and then having it appear at the top of the text you were typing. Is this the issue at hand? Also, could you please give us your build ID# and Operating System, and How reproducable this is?

Confirming. This bug is related to bug 94119 and bug 93399 and bug 82151. However, this issue deals with the Mail/News Compose window, not with HTML widgets. I've seen this as well once or twice. I've found that if you delete the final characters/newlines, this goes away. (very weird) from correspondence with the reporter.... Win98 0.9.3 you must use the keyboard arrows to move the caret to the end of the compose window. not use the mouse or scrollbar. changing summary to be more descriptive as well.

-->editor (probably a duplicate of one of the mentioned bugs)

assigning to Kin

--> mjudge (caret navigation)

Really giving to mjudge this time.

I was about to report this, but then I found this bug. Here is my write-up: STEPS TO REPRODUCE 1. Type at least 3 characters of text in a <textarea>. 2. On the last line of the <textarea> press down arrow (sends you to end of line as expected) then right arrow. EXPECTED RESULTS Cursor stays where it is, happy in the knowledge that the user is as far right as he can be. ACTUAL RESULTS Cursor unhappily jumps to the top of the <textarea>. This can also be reproduced by hitting the delete key followed by the right arrow. And in some cases, right arrow on its own is enough. Although sometimes, right arrow will send you to the start of the line not the start of the buffer. This is one of the most irritating bugs in the <textarea> editor.

text area nav. marking EDITORBASE

Related to bug 103039, which also covers the incorrect placement of the cursor when clicking to try to insert some text at the end of a line.

Logically (not visually), the caret is being placed at the front of the line. This seems ok since it behaves like hitting the "up" arrow if you are on line 1 (this also places the caret at the start of the line, logically (and visually). If we just got the visual to match the internal or logical position of the caret, I think we fixed the problem. Marking all. Plussing because this affects text areas.

Since this is blocking the 0.9.8 tracking bug, should the target be updated?

all of these things use the same code, so there's no need for more than one bug about this one problem. *** This bug has been marked as a duplicate of 82151 ***

verified.