Closed Bug 106855 Opened 19 years ago Closed 19 years ago

Down arrow key at last empty line of textarea moves caret to end of line above

Categories

(Core :: Layout: Form Controls, defect)

defect
Not set
normal

Tracking

()

VERIFIED FIXED
mozilla1.0

People

(Reporter: kazhik, Assigned: mjudge)

References

Details

(Keywords: regression, testcase, Whiteboard: have patch, need r/sr)

Attachments

(2 files, 2 obsolete files)

Down arrow key moves caret upward at the bottom of textarea.

Hit Enter key and down arrow key in this description textarea.
The caret moves upward with down arrow key.

Build: 2001102503/Win2k
This may be a dup of bug 82151.
I was not able to reproduce the description you have given.

bug 82151 says that when user presses right arrow OR ctrl+right arrow, the
cursor loops through the textarea control.Is this what you are seeing too?
 
Steps to reproduce.

1. Paste into textarea text so that vertical scrollbar will appear.
2. Go to the middle of the text end press ENTER in the middle of some word.

Results for me :
Scrolling upward is not available. All text which is upper than caret position
become invisible.

After some manipulation with Enter key , Back (delete) key and Ctrl-Z text in
the textarea might be totally mixed. Textarea behaviour is very unstable.
over to kin
Assignee: rods → kin
--> mjudge (caret/selection navigation)
Assignee: kin → mjudge
Wait, the updated description doesn't match the inital one.  I can reproduce the
inital one.

type some text.  Press Enter.  Press Down.
The cursor moves up a line.

Win2k build 2001120108
Editing in multiline text area is really screwed. Here's a test case:

a) Paste a large amount of text.
b) Go down by pressing Pg Dn
c) Try going up by pressing the 'Up' array key.

You will jump back to the original position from where y9ou started using 'Pg Dn'.
Extremely irritating with typing largish stuff.

This with Galeon 1.0 (using 0.9.6)
not able to reproduce scenarios mentioned in original comment and comment #3, 
#6.
But, I do see the behaviour mentioned in comment #7. 

Changing summary.

Keywords: testcase
Summary: Down arrow key moves caret upward at the bottom of textarea → caret positioning in a multiline textarea does not change with pgdn or pgup
Attached file testcase
refer to steps mentioned in comment #7.
Wait, Biswapesh and Madhur. That is not what original reporter said.
That is a different bug.

What reporter said comes from Japanese site
http://bugzilla.mozilla.gr.jp/show_bug.cgi?id=1490
Translation is below. comment #6 said the same thing.
comment #3 and comment #7 is different bugs from this.

I confirmed at Mozilla0.9.7/Linux 2001122108.

steps to reproduce
1. Type a few lines in a textarea.
2. Place a newline at end of last line, creating an empty line.
3. Press Down key at last empty line.

at step 3, caret jump to above line.

comment #7 is Bug 4302.

Summary changed to more detailed than original.
Summary: caret positioning in a multiline textarea does not change with pgdn or pgup → Down arrow key at last empty line of textarea moves caret to end of line above
*** Bug 116202 has been marked as a duplicate of this bug. ***
*** Bug 120632 has been marked as a duplicate of this bug. ***
*** Bug 113260 has been marked as a duplicate of this bug. ***
Textarea editing should be really fixed as soon as possible but at least in
mozilla1.0.
Not platform specific.
OS: Windows 2000 → All
Hardware: PC → All
I found the reason of this bug at nsTextInputSelectionImpl::CompleteMove().
http://lxr.mozilla.org/seamonkey/source/layout/html/forms/src/nsGfxTextControlFrame2.cpp#983
It seems that an execution of mFrameSelection->HandleClick() move the caret to
the line above  only when the caret is at the last empty line.
I don't know whether this movement is a bug of HandleClick() or not.

I wrote an ad hoc patch of CompleteMove() to avoid HandleClick().
This patch fix this bug.
Furthermore, it seems to fix some other bugs of strange movements of the caret.
see Bug 113260 and comment 70 of Bug 82151
http://bugzilla.mozilla.org/show_bug.cgi?id=82151#c70
Attached patch a patch to avoid HandleClick() (obsolete) — Splinter Review
Try this patch. I welcome any comments.
*** Bug 101124 has been marked as a duplicate of this bug. ***
keyboard nav in text areas dupe. dont know number. marking 1.0 and EDITORBASE.
Status: NEW → ASSIGNED
Whiteboard: EDITORBASE DUPME
Target Milestone: --- → mozilla1.0
Blocks: 82151
Let's not dupe this against some other bug when it's got a patch!  

mjudge, can you take a look at this patch please? Thanks.
Keywords: mozilla0.9.9
I understood why mFrameSelection->HandleClick() works wrongly.
Try my new patch.

Attached patch a new patch to CompleteMove() (obsolete) — Splinter Review
This is a patch to make HandleClick() works well.
Attachment #66076 - Attachment is obsolete: true
*** Bug 116490 has been marked as a duplicate of this bug. ***
Added some keywords, maybe it gets some attention.
Keywords: mozilla1.0patch
Whiteboard: EDITORBASE DUPME → have patch, need r/sr
*** Bug 123943 has been marked as a duplicate of this bug. ***
I've patched our builds of Mozilla with the patch to CompleteMove() and this bug
seems to be fixed with the patch. However the bug 82151 is still present.
Now we need to find someone who can give r/sr to the patch - mjudge,kin?
Blocks: 108120
No longer blocks: 82151
Comment on attachment 66665 [details] [diff] [review]
a new patch to CompleteMove()

r=jfrancis
Attachment #66665 - Flags: review+
*** Bug 124172 has been marked as a duplicate of this bug. ***
Comment on attachment 66665 [details] [diff] [review]
a new patch to CompleteMove()

+  HINT hint = (aExtend) ? HINTRIGHT : HINTLEFT;

Basing the hint on aExtend is/was a bad idea since it doesn't take into account
direction. It just means collapse or extend the selection. It's probably
better/consistent to just do:

+  HINT hint = HINTLEFT;

When adding braces to if statements:

+	 if (NS_SUCCEEDED(result) && tagName.get() == nsHTMLAtoms::br) {

you should always follow the style in the surrounding code or file. So the
brace should probably be on the next line.

sr=kin@netscape.com with those changes. Thanks for fixing this!!
Attachment #66665 - Flags: superreview+
Attached patch revised patchSplinter Review
OK. I revised the patch.
Attachment #66665 - Attachment is obsolete: true
Shotaro, I think you can check the revised patch in based on kin's comments. If
you don't have the priviledge, please, find someone to do it for you.
fix landed on trunk
Status: ASSIGNED → RESOLVED
Closed: 19 years ago
Resolution: --- → FIXED
verified fixed on 
win2000 buildID: 2002-03-22-05trunk 
Status: RESOLVED → VERIFIED
You need to log in before you can comment on or make changes to this bug.