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

Status: VERIFIED FIXED

(Core :: Layout: Form Controls, defect)

Description

[Koike Kazuhiko]

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

Comment 1

[Koike Kazuhiko]

This may be a dup of bug 82151.

Comment 2

[Madhur Bhatia]

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?
 

Comment 3

[Andrei Leo]

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.

Comment 4

[rods (gone)]

over to kin

Comment 5

[kinmoz]

--> mjudge (caret/selection navigation)

Comment 6

[Neil Marshall]

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

Comment 7

[Biswapesh Chatterjee]

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)

Comment 8

[Madhur Bhatia]

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.

Comment 9

[Madhur Bhatia]

Attachment: testcase

refer to steps mentioned in comment #7.

Comment 10

[Shotaro Kamio]

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 11

[Shotaro Kamio]

comment #7 is Bug 4302.

Summary changed to more detailed than original.

Comment 12

[Russell Odom]

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

Comment 13

[Christopher Aillon (sabbatical, not receiving bugmail)]

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

Comment 14

[Christopher Aillon (sabbatical, not receiving bugmail)]

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

Comment 15

[Tom Mraz]

Textarea editing should be really fixed as soon as possible but at least in
mozilla1.0.
Not platform specific.

Comment 16

[Shotaro Kamio]

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

Comment 17

[Shotaro Kamio]

Attachment: a patch to avoid HandleClick()

Try this patch. I welcome any comments.

Comment 18

[Terri Preston]

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

Comment 19

[anthonyd]

keyboard nav in text areas dupe. dont know number. marking 1.0 and EDITORBASE.

Comment 20

[Asa Dotzler [:asa]]

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.

Comment 21

[Shotaro Kamio]

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

Comment 22

[Shotaro Kamio]

Attachment: a new patch to CompleteMove()

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

Comment 23

[Kathleen :Brade]

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

Comment 24

[Tom Mraz]

Added some keywords, maybe it gets some attention.

Comment 25

[Shotaro Kamio]

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

Comment 26

[Tom Mraz]

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 27

[Joe Francis]

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

r=jfrancis

Comment 28

[Terri Preston]

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

Comment 29

[kinmoz]

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=[e-mail] with those changes. Thanks for fixing this!!

Comment 30

[Shotaro Kamio]

Attachment: revised patch

OK. I revised the patch.

Comment 31

[Tom Mraz]

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.

Comment 32

[Joe Francis]

fix landed on trunk

Comment 33

[Madhur Bhatia]

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