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)
Tracking
()
VERIFIED
FIXED
mozilla0.9
People
(Reporter: minter, Assigned: sfraser_bugs)
References
Details
(Whiteboard: [QAHP] patch)
Attachments
(3 files)
(deleted),
patch
|
Details | Diff | Splinter Review | |
(deleted),
text/html
|
Details | |
(deleted),
patch
|
Details | Diff | Splinter Review |
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•24 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•24 years ago
|
Component: Browser-General → HTML Form Controls
Comment 2•24 years ago
|
||
Confirmed for Linux build 20000921.
Marking OS as ALL as per James comment.
Status: UNCONFIRMED → NEW
Ever confirmed: true
OS: Linux → All
Updated•24 years ago
|
Status: NEW → ASSIGNED
Comment 9•24 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)
Comment 10•24 years ago
|
||
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•24 years ago
|
||
*** Bug 65216 has been marked as a duplicate of this bug. ***
Comment 12•24 years ago
|
||
*** Bug 61658 has been marked as a duplicate of this bug. ***
Comment 13•24 years ago
|
||
*** Bug 67211 has been marked as a duplicate of this bug. ***
Comment 14•24 years ago
|
||
*** Bug 62477 has been marked as a duplicate of this bug. ***
Comment 15•24 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•24 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•24 years ago
|
||
Still happens for me when pressing the end key. 2001 022020 Win98.
Assignee | ||
Comment 19•24 years ago
|
||
Drag back to 0.9. I have a patch.
Target Milestone: Future → mozilla0.9
Assignee | ||
Comment 20•24 years ago
|
||
Assignee | ||
Comment 21•24 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
Comment 22•24 years ago
|
||
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•24 years ago
|
||
Assignee | ||
Comment 24•24 years ago
|
||
Assignee | ||
Comment 25•24 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.
Comment 26•24 years ago
|
||
Comment 27•24 years ago
|
||
r=dbaron
Assignee | ||
Comment 28•24 years ago
|
||
Fix checked in.
Status: ASSIGNED → RESOLVED
Closed: 24 years ago
Resolution: --- → FIXED
Comment 29•24 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.
Description
•