build 2000113008 linux. how to reproduce: 1. click the add comment text field. 2. type mdqlwdzsieeerjm. and press enter. 3. type meepmeep. 4. press ctrl-e, the cursor moves up a few pixels. if you now press right arrow key twice, the cursor moves to the beginning of the line again. if you move cursor to the end of the last line with arrow keys this doesn't happen. this odd behaviour also occurs if you click with mouse on the right side of the text box, or move down with arrow key from an above line to the end of last one.
handing to kin to take a look and cc akkana
Assignee: beppe → kin
Yes, I can reproduce this in yesterday's build. The caret doesn't actually move up; instead, it gets smaller (the bottom part disappears), which probably means that the selection is ending up on a frame other than where it was previously; this may be what confuses it subsequently in the right-arrow. So the selection routine to go to end of line is doing the wrong thing, and the routine that moves right is probably also wrong (but we won't know until we know where the selection is after the end-of-line).
Status: UNCONFIRMED → NEW
Ever confirmed: true
Akkana is correct, the caret isn't moving up, I think the selection code may be attatching the caret to a BR frame, which has a small height, at the end of the line. In any case this is a caret navigation issue, and should probably go to email@example.com who now handles all things selection.
Assignee: kin → anthonyd
setting priority and milestone. anthonyd
Status: NEW → ASSIGNED
Priority: P3 → P2
Target Milestone: --- → mozilla0.9
adding keywords and nsbeta1+
Keywords: correctness, nsbeta1
*** Bug 65932 has been marked as a duplicate of this bug. ***
*** This bug has been marked as a duplicate of 53610 ***
Status: ASSIGNED → RESOLVED
Last Resolved: 18 years ago
Resolution: --- → DUPLICATE
verified in 2/5 build.
Status: RESOLVED → VERIFIED
You need to log in before you can comment on or make changes to this bug.