From Bugzilla Helper: User-Agent: Mozilla/5.0 (X11; U; Linux 2.4.0-2mdk i586; en-US; m18) Gecko/20010118 BuildID: 2001011821 The insertion mark always seems to end up in the wrong place in the previous or next line if I move the mark up and down with the arrow keys. Reproducible: Always Steps to Reproduce: Type in several lines of text into a form text box. Then move the cursor in the middle of one of the lines. Hit the up or down arrow. Actual Results: One would expect that in moving between lines that the insertion mark would stay in the same relative position in each line, but it doesn't. There seems to be a variable that isn't getting cleared properly. I start a line and type mark then up arrow and the insertion mark ends up four characters from the end of the previous line. I go back and backspace over mark and retype it, press up arrow and the mark ends up eight characters from the end of the previous line. Do it again and it ends up twelve characters. Expected Results: If I am between the third and fourth characters of a line and I press up or down arrow, I should stay between the third and fourth characters of a line. Seems to have appearred just now. Didn't see this in previous builds.
Confirming with build 2001011820 on NT4, although I see this somewhat different: Type several lines in a textarea form field, like the additional comments on this page. Move the cursor in the middle of one line. Press cursor up or down. Expected: cursor is in the same column one line above or below, respectively. Actual: cursor moves also one position to the right. This only happens when pressing up or down for the first time. On subsequent up or down key strokes, the cursor stays in the same column as I would expect. After moving the cursor by some other means (right, left, entering some text, mouse) and hitting up or down again, the weird behaviour returns.
Status: UNCONFIRMED → NEW
Ever confirmed: true
OS: Linux → All
Hardware: PC → All
pretty sure this is a dup -> sfraser
Assignee: rods → sfraser
Component: Form Submission → Editor
QA Contact: vladimire → sujay
probably a dup of bug 51136
Assignee: sfraser → anthonyd
Yes, probably a dup of bug 51136, although I don't get the behaviour described there. But Mozilla does it wrong anyway.
*** Bug 66188 has been marked as a duplicate of this bug. ***
I agree; I think this is a duplicate *** This bug has been marked as a duplicate of 51136 ***
Status: NEW → RESOLVED
Last Resolved: 18 years ago
Resolution: --- → DUPLICATE
Target Milestone: --- → mozilla0.8
verified in 1/22 build.
Status: RESOLVED → VERIFIED
You need to log in before you can comment on or make changes to this bug.