88024 - Down arrow key creates fake line break at the end of a TEXTAREA

Status: VERIFIED FIXED

(Core :: Layout: Form Controls, defect, P3)

Description

[Matthew T (active 1999-2002)]

To reproduce:
1.  Click in the `Additional comments' field in this bug report.
2.  Press `a'.
3.  Watch the caret very closely as you press the Down arrow key.
4.  Note that nothing special happens.
5.  Press Enter.6.  Notice that one line break is created, as it should be.
7.  Now hold down Backspace and Delete until you are sure that any trace of
    text is deleted from the textarea.8.  Repeat steps 2 and 3.
9.  Notice that the caret moves one pixel to the right.
10. Repeat step 5.

What should happen:
*   One line break is created.

What actually happens:
*   Two line breaks are created.
Problem occurs with:
*   The TEXTAREA in every single smegging bug I comment on, build 2001062608,
    Mac OS 9.1
Problem does not occur with:
*   The plain-text message composition window in the same build.

Comment 1

[Matthew T (active 1999-2002)]

When I entered that bug report, there was a completely blank line between
`created' and `Problem occurs', and a completely blank line between `9.1' and
`Problem doesn't'.

So, it would appear that the extra line breaks aren't really there, the TEXTAREA
is just interpreting something as a line break when it shouldn't be. Or something.

Comment 2

[Nick Stenz]

confirmed for win32 builds also- this one has been bugging me for months. =\

Comment 3

[Kathleen :Brade]

-->mjudge since rods is on sabbatical

Comment 4

[rubydoo123]

a

Comment 5

[Brent]

Reproducable error in editor on build 2001073003:

0. Type up some text, then move cursor to end of last line of text.
(you can skip step 0)
1. Hit Enter, and type in a new line of text.  Leave cursor at end of line.
2. Hit down arrow.  Cursor moves a few pixels to the right.
3. Hit a character.

A new line with that character will be added to the text,
which is wrong.  If instead of a character, the Enter key is hit,
two new lines are added.

This occasionally happens on any line, not just the last one, with either the
end or down arrow key.  On step 2, if the end key is hit instead of down
arrow, the cursor moves a few pixels to the right but editor appears to behave
correctly on step 3.

Comment 6

[timeless]

Brent <[e-mail]> filed bug 93549

Comment 7

[rubydoo123]

look at the comments in bug 93549

Comment 8

[rubydoo123]

i think this is a consequence of the _moz_dirty br

Comment 9

[anthonyd]

adding [e-mail] to the cc list.
the problem here seems to be that the caret gets placed *after* the <br>.  then
once input begins, the new input is placed after the <br>. 

anthonyd

Comment 10

[anthonyd]

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

Comment 11

[rubydoo123]

--> kin

Comment 12

[Tim Powell]

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

Comment 13

[kinmoz]

This is a caret navigation problem in nsTextInputSelectionImpl::CompleteMove() 
which brade added. I believe all we need to do is check to see if the last child 
child (offset-1) is a BR, if so, then make sure we place the caret before it at 
offset-1.

Note that this problem happens in empty textareas since empty textareas contain 
a BR.

Comment 14

[kinmoz]

Attachment: Patch Rev 1 (Avoid placing caret after the last BR)

Comment 15

[kinmoz]

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

Comment 16

[kinmoz]

Attachment: Patch Rev 2 (Fixes a leak I added in Patch Rev 1)

Comment 17

[kinmoz]

--> 0.9.6

Comment 18

[Kathleen :Brade]

Comment on attachment 51778 [details] [diff] [review]
Patch Rev 2 (Fixes a leak I added in Patch Rev 1)

r=brade

Comment 19

[Simon Fraser [no longer active]]

Comment on attachment 51778 [details] [diff] [review]
Patch Rev 2 (Fixes a leak I added in Patch Rev 1)

sr=sfraser

Comment 20

[kinmoz]

Fix checked into TRUNK:

    mozilla/layout/html/forms/src/nsGfxTextControlFrame2.cpp  revision 1.166

Comment 21

[Madhur Bhatia]

I still see the bug in buildID:- 2001-10-09-09-trunk.
Which trunk build was the fix checked in?

Comment 22

[Boris Zbarsky [:bzbarsky]]

based on that comment, it was checked in midday on Oct 9.  So builds starting
with the evening of Oct 9 should have the fix....

Comment 23

[Madhur Bhatia]

verified fixed on trunk build :- 
2001-10-11-09trunk win2k 
2001-10-10-20trunk macOS X 
2001-10-11-08trunk RedHat linux 7.1

adding keyword 'vbranch'

Comment 24

[Brent]

I still see this bug in 0.9.5 (build 2001101117).  Try the test case in bug 93549.

Comment 25

[kinmoz]

Brent, I checked this fix into the TRUNK, after 0.9.5 branched, so it will
not appear in any 0.9.5 build. Look for it in TRUNK builds or 0.9.6.

I verified that bug 93549 is indeed fixed on the TRUNK. Marking bug FIXED.

Comment 26

[Madhur Bhatia]

when will this fix be moved into the branch build?
verified fixed in trunk build

Comment 27

[kinmoz]

Madhur - which branch build are you referring to?

If you're talking about 0.9.5, it's not a stop-ship problem so it's not going to 
make the 0.9.5 train.

Comment 28

[Madhur Bhatia]

I was refering to the 0.9.5 build

Comment 29

[kinmoz]

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

Comment 30

[Madhur Bhatia]

will this make the mozilla0.9.6?

Comment 31

[kinmoz]

Yes, it will be in 0.9.6.

Comment 32

[Madhur Bhatia]

i see this bug again on win2k in build ID : 2002-03-11-11trunk build and 
2002-03-11-0.9.9 branch build.

the patch that fixed this bug was supposed to make it to the mozilla 0.9.6 
branch. Re-opening bug. Removing keyword vbranch.

Comment 33

[Madhur Bhatia]

my mistake :-|
this bug regarding false line breaks is fixed in the above mentioned builds
comment # 32.

What I saw was the caret moving one pixel to the right (described in original
comment). Will write up another bug for that.

Resolving this bug fixed.

Comment 34

[Madhur Bhatia]

verified