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

VERIFIED FIXED in mozilla0.9.6

Status

()

Core
Layout: Form Controls
P3
normal
VERIFIED FIXED
17 years ago
16 years ago

People

(Reporter: Matthew Paul Thomas, Assigned: kinmoz)

Tracking

Trunk
mozilla0.9.6
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

(Whiteboard: [C], [caret] [EDITORBASE] [CANDIDATE_094] fixed on trunk)

Attachments

(1 attachment, 1 obsolete attachment)

(Reporter)

Description

17 years ago
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.
(Reporter)

Comment 1

17 years ago
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.
Summary: Down arrow key creates invisible line break at the end of a TEXTAREA → Down arrow key creates fake line break at the end of a TEXTAREA

Comment 2

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

Comment 3

17 years ago
-->mjudge since rods is on sabbatical
Assignee: rods → mjudge
OS: Mac System 8.5 → All
Hardware: Macintosh → All

Comment 4

17 years ago
a
Priority: -- → P3
Target Milestone: --- → mozilla1.0

Comment 5

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

17 years ago
Brent <simpleeqbest@hotmail.com> filed bug 93549

Comment 7

17 years ago
look at the comments in bug 93549
Assignee: mjudge → anthonyd
Whiteboard: [caret]
Target Milestone: mozilla1.0 → mozilla0.9.5

Updated

17 years ago
Blocks: 93549

Comment 8

17 years ago
i think this is a consequence of the _moz_dirty br

Updated

17 years ago
Status: NEW → ASSIGNED
Whiteboard: [caret] → [C], [caret]

Comment 9

17 years ago
adding kin@netscape.com 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

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

Comment 11

17 years ago
--> kin
Assignee: anthonyd → kin
Status: ASSIGNED → NEW

Comment 12

17 years ago
*** Bug 100926 has been marked as a duplicate of this bug. ***
(Assignee)

Comment 13

17 years ago
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.
(Assignee)

Comment 14

17 years ago
Created attachment 51104 [details] [diff] [review]
Patch Rev 1 (Avoid placing caret after the last BR)
(Assignee)

Updated

17 years ago
Status: NEW → ASSIGNED
Whiteboard: [C], [caret] → [C], [caret] FIX IN HAND

Updated

17 years ago
Attachment #51104 - Flags: review+
(Assignee)

Comment 15

17 years ago
*** Bug 96799 has been marked as a duplicate of this bug. ***
(Assignee)

Comment 16

17 years ago
Created attachment 51778 [details] [diff] [review]
Patch Rev 2 (Fixes a leak I added in Patch Rev 1)
(Assignee)

Comment 17

17 years ago
--> 0.9.6
Target Milestone: mozilla0.9.5 → mozilla0.9.6
(Assignee)

Updated

17 years ago
Whiteboard: [C], [caret] FIX IN HAND → [C], [caret] EDITORBASE FIX IN HAND

Comment 18

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

r=brade
Attachment #51778 - Flags: review+

Updated

17 years ago
Attachment #51104 - Attachment is obsolete: true

Comment 19

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

sr=sfraser
Attachment #51778 - Flags: superreview+
(Assignee)

Comment 20

17 years ago
Fix checked into TRUNK:

    mozilla/layout/html/forms/src/nsGfxTextControlFrame2.cpp  revision 1.166
Status: ASSIGNED → RESOLVED
Last Resolved: 17 years ago
Resolution: --- → FIXED
Whiteboard: [C], [caret] EDITORBASE FIX IN HAND → [C], [caret] [EDITORBASE] [CANDIDATE_094] fixed on trunk

Comment 21

17 years ago
I still see the bug in buildID:- 2001-10-09-09-trunk.
Which trunk build was the fix checked in?
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

17 years ago
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'
Keywords: vbranch

Comment 24

17 years ago
I still see this bug in 0.9.5 (build 2001101117).  Try the test case in bug 93549.
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
(Assignee)

Comment 25

17 years ago
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.
Status: REOPENED → RESOLVED
Last Resolved: 17 years ago17 years ago
Resolution: --- → FIXED

Comment 26

17 years ago
when will this fix be moved into the branch build?
verified fixed in trunk build
(Assignee)

Comment 27

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

17 years ago
I was refering to the 0.9.5 build
(Assignee)

Comment 29

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

Comment 30

17 years ago
will this make the mozilla0.9.6?
(Assignee)

Comment 31

17 years ago
Yes, it will be in 0.9.6.

Comment 32

16 years ago
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.
Status: RESOLVED → REOPENED
Keywords: vbranch
Resolution: FIXED → ---

Comment 33

16 years ago
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.
Status: REOPENED → RESOLVED
Last Resolved: 17 years ago16 years ago
Resolution: --- → FIXED

Comment 34

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