Menu
Just recently I have noticed out text inputs having a display issue in Google Chrome but only when the text is empty.
Notice how in the top image, when the input is empty, the cursor is too high within the text input.
But once we type some text it corrects itself:
JSFiddle to illustrate. May require Google Chrome version: 38.0.2125.101 m
HTML:
<input name="tb_password" type="password" id="tb_password" class=" validate[required,custom[password]]" placeholder="Type your password here" autocomplete="off" style=" margin: 0; line-height: 46px; "> CSS:
input[type="text"], input[type="password"] { width: 100%; height: 46px; line-height: 46px; font-size: 11pt; color: #555 !important; text-indent: 15px; border-top: solid 1px #c5c5c5; border-left: solid 1px #c5c5c5; border-bottom: solid 1px #dadada; border-right: solid 1px #dadada; background: #fff; -webkit-box-shadow: inset 0px 1px 5px 0px rgba(0, 0, 0, .1); box-shadow: inset 0px 1px 5px 0px rgba(0, 0, 0, .1); } 
232
To move the cursor to the end of an input field: Use the setSelectionRange() method to set the current text selection position to the end of the input field. Call the focus() method on the input element. The focus method will move the cursor to the end of the input element's value.
We can place the cursor at the end of the text in a text input element by using different JavaScript functions. HTMLInputElement.setSelectionRange (): The HTMLInputElement.setSelectionRange () is a method that sets the start and end positions of the current text selection in an <input> or <textarea> element.
// To get cursor position, get empty selection range var oSel = document.selection.createRange(); // Move selection start to 0 position
@alec: I agree searching for cursor instead of caret may yield more result. As pointed out elsewhere, I learned that caret is the more appropriate term. A cursor represents a location in anything while a caret represents a location specifically in text. Use field.selectionStart example in this answer.
Looks like this is a regression bug in the Chromium 38 engine. I can reproduce in Chrome 38.* and Opera 25.* (which uses Chromium 38).
As pointed out by @JackieChiles it appears to be a regression of this [closed as obselete] bug: https://code.google.com/p/chromium/issues/detail?id=47284
As suggested in the closed bug, I have logged a new one. https://code.google.com/p/chromium/issues/detail?id=426802&thanks=426802&ts=1414143535
And have also referenced another reported bug which appears to highlight the same bug, yet fails to define the exact issue in a generic way. https://code.google.com/p/chromium/issues/detail?id=394664
As detailed in other answers above the workaround is to avoid using a pixel-based line-height attribute. For example swapping line-height:50px to line-height:1em or line-height:100% will yield more expected behaviour.
161
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With
