caret moves to top when moved with keyboard to end of content

VERIFIED DUPLICATE of bug 82151

Status

()

P3
normal
VERIFIED DUPLICATE of bug 82151
17 years ago
5 years ago

People

(Reporter: tomstdenis, Assigned: mjudge)

Tracking

Trunk
mozilla1.0
x86
All
Points:
---
Dependency tree / graph

Firefox Tracking Flags

(Not tracked)

Details

(Whiteboard: EDITORBASE+[Hixie-P0][Hixie-1.0][caret])

(Reporter)

Description

17 years ago
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

Comment 2

17 years ago
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?

Comment 3

17 years ago
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.
Status: UNCONFIRMED → NEW
Ever confirmed: true
Summary: Scrolling in windows. → caret moves to top when moved with keyboard to end of content

Comment 4

17 years ago
-->editor (probably a duplicate of one of the mentioned bugs)
Assignee: ducarroz → beppe
Component: Composition → Editor
Product: MailNews → Browser
QA Contact: sheelar → sujay

Comment 5

17 years ago
assigning to Kin
Assignee: beppe → kin
Priority: -- → P3
Whiteboard: [caret]
Target Milestone: --- → mozilla0.9.5

Comment 6

17 years ago
--> mjudge (caret navigation)
Target Milestone: mozilla0.9.5 → ---

Comment 7

17 years ago
Really giving to mjudge this time.
Assignee: kin → mjudge
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.
Whiteboard: [caret] → [Hixie-P0][Hixie-1.0][caret]

Updated

17 years ago
Blocks: 115520

Comment 9

17 years ago
text area nav.  marking EDITORBASE
Status: NEW → ASSIGNED
Whiteboard: [Hixie-P0][Hixie-1.0][caret] → EDITORBASE[Hixie-P0][Hixie-1.0][caret]
Target Milestone: --- → mozilla1.0

Comment 10

17 years ago
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.
Blocks: 103039

Comment 11

17 years ago
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.
OS: Windows 98 → All
Whiteboard: EDITORBASE[Hixie-P0][Hixie-1.0][caret] → EDITORBASE+[Hixie-P0][Hixie-1.0][caret]

Comment 12

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

Comment 13

17 years ago
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 ***
Status: ASSIGNED → RESOLVED
Last Resolved: 17 years ago
Resolution: --- → DUPLICATE

Comment 14

17 years ago
verified.
Status: RESOLVED → VERIFIED
You need to log in before you can comment on or make changes to this bug.