Bug 86423 – Clicking/tapping close to the upper border of the input field moves the cursor to the beginning.

• Component: Forms
• Status: UNCONFIRMED

[Onur Tekdas]

Created attachment 141832 [details]
4 text input fields. Test by clicking upper border of the input field. In the last three example, cursor will be moved to the beginning of the input.

Issue: clicking/tapping close to the upper border of a text input field moves the cursor to the beginning. This is different than Bug 15695 since it is generated by clicking on a specific region of the input field. This is especially problematic for mobile browsers because tapping is not precise.

Expected behavior: the cursor should be moved to the closest position in the input field.

Platforms: tested on PC/Mac/Android/iPhone with Chrome and Safari browsers.

Symptoms: AFAIK this only happens if height,padding,border properties of the input field is set. Setting style="height:initial; padding:0; border:0", it works as expected.

[Tony Chang]

Not sure who has the cycles to fix this.

[Ryosuke Niwa]

This is working as expected as far as I know. We might consider something differn for mobile browsers or inside input element but I'm skeptical as to whether that's a problem we should be solving in WebCore or not.

[Ojan Vafai]

The tricky thing here is whether clicking in the padding above the first line or the padding below the last line should count as part of the first/last line. In the case of a text input or textarea with the default amount of padding, the user clearly would expect it to count. If, however, you increased the padding to 20px, I expect most users would expect it to not count.

My intuition is that we should change to consider clicking in the padding to be part of the line because the common case, by many orders of magnitude is that the padding is very small and users would expect clicking it it to be like clicking in the line.

[Eric Seidel (no email)]

I know we consider clicks in space above the first line to be part of the first line.  But maybe we shouldn't for single-line input?  It seems reasonable to disable that behavior in the single-line case.

[Ryosuke Niwa]

(In reply to comment #4)
> I know we consider clicks in space above the first line to be part of the first line.  But maybe we shouldn't for single-line input?  It seems reasonable to disable that behavior in the single-line case.

Yeah, that's what I'm thinking as well. But then we'll have to maintain two different behaviors :(  I know there's some Mac-ism involved here so not sure if we can just change that unilaterally.

I do agree with Ojan that the user expectation will probably vary depending on the amount of padding we have. If we have, say, 100px paddings, then I don't think they'll expect this as a bug.

Maybe we can use some heuristics like do the current behavior if we're more than 20% of line-height away from edges?

[Ojan Vafai]

(In reply to comment #4)
> I know we consider clicks in space above the first line to be part of the first line.  But maybe we shouldn't for single-line input?  It seems reasonable to disable that behavior in the single-line case.

It's the other way around. To be more accurate, we only consider clicks above the first line to be part of the first line on Windows to match Windows platform expectations.

I'm suggesting something slightly different. If you click in the padding above the first line we should consider it part of the first line on all platforms.

[Ojan Vafai]

The solution I propose in comments 3/6 will not work. Specifically if you have a textarea/contentEditable div with the fixed height and click below the contents, the cursor should go at the end of the last line on Linux/Mac.

<div contentEditable style="padding: 20px; border: 2px solid; width: 100px; height: 100px">foo bar baz lorem ipsum dolor</div>

Clicking below "dolor" should put the cursor at the end of the line on Linux/Mac.

I'm not really sure what we can do to fix this. Someone suggested we could use a heuristic based off the line-height of a certain number of pixels above the first line / below the last line that we consider part of that line. That could work to fix default textarea/input padding at least.

FWIW, the original poster was wrong that this happens on Windows. This bug doesn't happen on Windows because platform convention there is to treat any click above the first line as being in the first line and similarly for the clicks below the last line.