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

--> mjudge (caret/selection navigation)

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.

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.

*** 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.

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

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.

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.

I understood why mFrameSelection->HandleClick() works wrongly. Try my new patch.

This is a patch to make HandleClick() works well.

*** Bug 116490 has been marked as a duplicate of this bug. ***

Added some keywords, maybe it gets some attention.

*** 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?

Comment on attachment 66665 [details] [diff] [review] a new patch to CompleteMove() r=jfrancis

*** 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!!

OK. I revised the patch.

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

verified fixed on win2000 buildID: 2002-03-22-05trunk