New issue
Advanced search Search tips

Issue 47284 link

Starred by 7 users

Issue metadata

Status: IceBox
Owner: ----
Closed: Aug 2012
EstimatedDays: ----
NextAction: ----
OS: ----
Pri: 2
Type: Bug

  • Only users with Commit permission may comment.

Sign in to add a comment

Cursor line-height bug on inputs

Reported by, Jun 23 2010

Issue description

Chrome Version       : 6.0.437.3 (Windows XP SP3)
URLs (if applicable) :
Other browsers tested:
Add OK or FAIL after other browsers where you have tested this issue:
     Safari 4: N/A
  Firefox 3.x: N/A
         IE 7: N/A
         IE 8: N/A

What steps will reproduce the problem and what happens?
Adding the css property line-height on input type='text' displays inconsistent behavior:
    1. Cursor height is same height as line-height with a minimum height of 16px (this may be design?)
    2.Initial cursor on an empty text input overflows outside of the input box.
    3. Cursor's vertical-position may shift upwards after characters are inserted into the text box (via keyboard, javascript, and pasting the input) for smaller line-height values. Cursor height may also shrink relative to the initial cursor height in issue 1.
    4. If the input initially has a value issue 1 does not apply.

What is the expected result?
I'm not 100% sure what the correct behavior is. I kinda want the cursor to be the height of the text/font irregardless of line-height. But if the lineHeight = 1000px, fontSize = 12px and the text-box height = 20px the user may be confused if the cursor isn't displayed when the field is focused because it is ~500px below the input (and completely hidden); though that UI issue could just be left to the coder.

Please provide any additional information below. Attach a screenshot if

Visit here: to see the problem.
just want to point out that this bug is still there.
Back again to let you know it still isn't fixed.

Comment 3 by Deleted ...@, Oct 19 2011

outline:none in your class

Comment 4 Deleted

Regarding comment #3 above:

outline:none seems to be unrelated to this issue.  The problem still exists.  Chrome seems to initially draw the caret as tall as possible, but not taller than either the height or line-height of the text input.  After the text input receives character input from the keyboard, the caret resizes appropriately with the text.  Vertical  alignment still appears to be off at that point, favoring the top of the input and not the vertical-center.

Once the text input has received character input, the caret NEVER returns to it's initial full height, even if all characters are cleared from the input.  The only way to get it to return to it's initial (incorrect) full-height state is to refresh the browser.

EDIT: I'm using Google Chrome version 15.0.874.121 and this issue still exists.
I'd like to add to this that the text-indent property on a text input also seems to not be considered when drawing the initial caret.  The caret will initially be drawn at the leftmost pixel of the text input.  Once character data has been entered into the text input, the caret snaps into the (almost) correct position.  The vertical-alignment remains non-optimal, but at least the caret's horizontal position accurately indicates where text will the next character will be displayed.  Once again, it seems there is no way to get the caret back to it's original (incorrect) position without refreshing the page.
I'm using Google Chrome 17.0.963.79 and this issue is still there.

Comment 8 by, Mar 23 2012

Ha-ha! I think they`ve never looked at here and this will be never fixed...

Comment 9 by, Mar 23 2012

By the way - this is not just in Chrome, but also in Safari, so entirely in Webkit
Project Member

Comment 10 by, Aug 10 2012

Status: IceBox
Closing old bug as obsolete. Please file a new bug (with details) if this problem is still occurring for you.
Project Member

Comment 11 by, Oct 13 2012

Labels: Restrict-AddIssueComment-Commit
This issue has been closed for some time. No one will pay attention to new comments.
If you are seeing this bug or have new data, please click New Issue to start a new bug.
Project Member

Comment 12 by, Mar 11 2013

Labels: -Area-Undefined

Sign in to add a comment