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

VERIFIED FIXED in mozilla0.9

Status

()

Core
Layout: Form Controls
P3
minor
VERIFIED FIXED
18 years ago
17 years ago

People

(Reporter: H. Wade Minter, Assigned: Simon Fraser)

Tracking

Trunk
mozilla0.9
x86
All
Points:
---
Dependency tree / graph

Firefox Tracking Flags

(Not tracked)

Details

(Whiteboard: [QAHP] patch)

Attachments

(3 attachments)

(Reporter)

Description

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

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

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

Updated

18 years ago
Component: Browser-General → HTML Form Controls

Comment 2

18 years ago
Confirmed for Linux build 20000921.

Marking OS as ALL as per James comment.
Status: UNCONFIRMED → NEW
Ever confirmed: true
OS: Linux → All

Comment 3

18 years ago
really reassigning.
Assignee: asa → rods
QA Contact: doronr → ckritzer

Comment 4

18 years ago
sounds like a dup
Assignee: rods → beppe

Comment 5

18 years ago
future
Target Milestone: --- → Future

Comment 6

18 years ago
Updating QA contact.
QA Contact: ckritzer → bsharma

Updated

18 years ago
Status: NEW → ASSIGNED

Comment 7

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

Comment 8

18 years ago
Mine
Assignee: beppe → sfraser
Status: ASSIGNED → NEW

Comment 9

17 years ago
Adding "insertion point" to summary.  Probably related to bug 51747 (fixed).
Summary: Clicking on end of line in textbox puts cursor a few pixels higher than it should be → Clicking on end of line in textbox puts cursor a few pixels higher than it should be (insertion point)
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 (!)

Updated

17 years ago
Blocks: 62477

Comment 11

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

Comment 12

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

Comment 13

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

Comment 14

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

Comment 15

17 years ago
correct summary to use "caret"
Summary: Clicking on end of line in textbox puts cursor a few pixels higher than it should be (insertion point) → Clicking on end of line in textbox puts caret a few pixels higher than it should be (insertion point)

Comment 16

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

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

Comment 18

17 years ago
QA Contact Update
QA Contact: bsharma → vladimire

Updated

17 years ago
Whiteboard: [QAHP]
(Assignee)

Comment 19

17 years ago
Drag back to 0.9. I have a patch.
Target Milestone: Future → mozilla0.9
(Assignee)

Comment 20

17 years ago
Created attachment 30549 [details] [diff] [review]
Fix in nsCaret.cpp
(Assignee)

Comment 21

17 years ago
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
Status: NEW → ASSIGNED
Whiteboard: [QAHP] → [QAHP] patch
Blocks: 38370
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; }"?
(Assignee)

Comment 23

17 years ago
Created attachment 30603 [details]
Testcase with different line heights; edit this in composer
(Assignee)

Comment 24

17 years ago
Created attachment 30604 [details] [diff] [review]
Better fix that uses ascent+descent
(Assignee)

Comment 25

17 years ago
Thanks, dbaron, you are correct. I attached a testcase that shows that using 
ascent+descent is better than lineheight, and a new patch.
r=dbaron
(Assignee)

Comment 28

17 years ago
Fix checked in.
Status: ASSIGNED → RESOLVED
Last Resolved: 17 years ago
Resolution: --- → FIXED

Comment 29

17 years ago
Verifying on build 2001-04-13-04-trunk windows 98
Status: RESOLVED → VERIFIED
You need to log in before you can comment on or make changes to this bug.