53610 - Clicking on end of line in textbox puts caret a few pixels higher than it should be (insertion point)

Status: VERIFIED FIXED

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

Description

[H. Wade Minter]

Using 2000092110.

If you're typing text into a textarea on an HTML form (such as this bug report),
and you click the mouse at the end of a line of text, the cursor will be placed
a few pixels higher (such as in a superscript) than it should be.  Starting to
type resets it and things continue as normal.

This doesn't happen when you click in the middle of a line of text.

Comment 1

[James Lariviere]

I see this in win98 too when you hit the "end" button.

I think this bug should be directed to HTML FORM Controls.

Comment 2

[Matthew Cline]

Confirmed for Linux build 20000921.

Marking OS as ALL as per James comment.

Comment 3

[Doron Rosenberg (IBM)]

really reassigning.

Comment 4

[rods (gone)]

sounds like a dup

Comment 5

[rubydoo123]

future

Comment 6

[bsharma]

Updating QA contact.

Comment 7

[Matthew T (active 1999-2002)]

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

Comment 8

[Simon Fraser [no longer active]]

Mine

Comment 9

[Jesse Ruderman]

Adding "insertion point" to summary.  Probably related to bug 51747 (fixed).

Comment 10

[Scott Gifford (old account)]

I'm still seeing this in 2000122610.

A related problem (from bug #56325):

If I am in a TEXTAREA and have text selected elsewhere, when I middle-click past
the end of line (where the caret is shortened) to paste it, it pastes
incorrectly, sometimes going down to the next line, sometimes jumping up and
pasting there (!)

Comment 11

[Stephan Niemz]

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

Comment 12

[Jesse Ruderman]

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

Comment 13

[Jesse Ruderman]

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

Comment 14

[Jesse Ruderman]

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

Comment 15

[Kathleen :Brade]

correct summary to use "caret"

Comment 16

[:deanis74]

I'm not seeing this anymore with today's build.  It used to happen everytime I 
pressed the End key while in a textfield.  Can anyone confirm or deny?

Build: 2001021808 on Win2000

Comment 17

[Jesse Ruderman]

Still happens for me when pressing the end key.  2001 022020 Win98.

Comment 18

[Vladimir Ermakov]

QA Contact Update

Comment 19

[Simon Fraser [no longer active]]

Drag back to 0.9. I have a patch.

Comment 20

[Simon Fraser [no longer active]]

Attachment: Fix in nsCaret.cpp

Comment 21

[Simon Fraser [no longer active]]

The fix takes out the hard-coded caret height for zero-height <br> frames, 
replacing it with some code that gets the line height in the same way its gotten 
during reflow (see BRFrame::Reflow).

Looking for r/sr

Comment 22

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

Are you sure you want the frameRect.height (is that the height of the caret?) to
be the result of CalcLineHeight rather than just the ascent + descent of the
font?  What does this look like with the CSS rule "textarea { line-height: 2; }"?

Comment 23

[Simon Fraser [no longer active]]

Attachment: Testcase with different line heights; edit this in composer

Comment 24

[Simon Fraser [no longer active]]

Attachment: Better fix that uses ascent+descent

Comment 25

[Simon Fraser [no longer active]]

Thanks, dbaron, you are correct. I attached a testcase that shows that using 
ascent+descent is better than lineheight, and a new patch.

Comment 26

[kinmoz]

sr=[e-mail]

Comment 27

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

r=dbaron

Comment 28

[Simon Fraser [no longer active]]

Fix checked in.

Comment 29

[Vladimir Ermakov]

Verifying on build 2001-04-13-04-trunk windows 98