Closed Bug 53610 Opened 24 years ago Closed 24 years ago

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

Categories

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

x86
All
defect

Tracking

()

VERIFIED FIXED
mozilla0.9

People

(Reporter: minter, Assigned: sfraser_bugs)

References

Details

(Whiteboard: [QAHP] patch)

Attachments

(3 files)

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.
I see this in win98 too when you hit the "end" button. I think this bug should be directed to HTML FORM Controls.
Component: Browser-General → HTML Form Controls
Confirmed for Linux build 20000921. Marking OS as ALL as per James comment.
Status: UNCONFIRMED → NEW
Ever confirmed: true
OS: Linux → All
really reassigning.
Assignee: asa → rods
QA Contact: doronr → ckritzer
sounds like a dup
Assignee: rods → beppe
future
Target Milestone: --- → Future
Updating QA contact.
QA Contact: ckritzer → bsharma
Status: NEW → ASSIGNED
*** Bug 56325 has been marked as a duplicate of this bug. ***
Mine
Assignee: beppe → sfraser
Status: ASSIGNED → NEW
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 (!)
Blocks: 62477
*** Bug 65216 has been marked as a duplicate of this bug. ***
*** Bug 61658 has been marked as a duplicate of this bug. ***
*** Bug 67211 has been marked as a duplicate of this bug. ***
*** Bug 62477 has been marked as a duplicate of this bug. ***
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)
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
Still happens for me when pressing the end key. 2001 022020 Win98.
QA Contact Update
QA Contact: bsharma → vladimire
Whiteboard: [QAHP]
Drag back to 0.9. I have a patch.
Target Milestone: Future → mozilla0.9
Attached patch Fix in nsCaret.cpp (deleted) — Splinter Review
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; }"?
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
Fix checked in.
Status: ASSIGNED → RESOLVED
Closed: 24 years ago
Resolution: --- → FIXED
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.

Attachment

General

Created:
Updated:
Size: