Open Bug 860329 Opened 12 years ago Updated 1 year ago

<input> should scroll its text to the start on blur/lose focus

Categories

(Core :: Layout: Form Controls, enhancement)

Product:
Core
Component:
Layout: Form Controls
Type:
enhancement

Tracking

()

Status:
UNCONFIRMED

People

(Reporter: dtrebbien, Unassigned)

Details

Like Safari/Chrome/WebKit browsers, if a text input has text-overflow:ellipsis and the value needs to be truncated, the ellipsis should appear as soon as the input element loses focus. Steps to reproduce the problem: 1. Visit http://jsfiddle.net/zeBsw/ 2. Click on the first text box and enter a value wider than the text control's width. 3. Either tab to the next text box or click on the "Something to Click" button. The ellipsis does not appear until after tabbing back to the first text box. I have tested and found the issue in Firefox 20.0 and Firefox Aurora 22.0a2 (2013-04-10). Testing the above steps in Safari 6.0.3 and Chrome 26.0.1410.63, the ellipsis appears immediately when the first text box loses focus.
Chrome resets the scroll position of the text control as you tab away from it and that's what causing the ellipsis to appear because the text then overflows. Firefox does not change the scroll position when you tab away and thus there is no overflowing text and that's why no ellipsis appear at the end. Changing the bug Summary to better reflect the issue.
Severity: normal → enhancement
Component: Layout: Text → Layout: Form Controls
Summary: The ellipsis for an input with text-overflow:ellipsis should appear on blur/lose focus → <input> should scroll its text to the start on blur/lose focus
Version: 20 Branch → unspecified
It's not clear to me why this scrolling is a desirable behavior, exactly.
Mats' explanation helps to clear up some of the confusion in my mind about this. Is the thinking, then, that this ticket is a request to add some way to scroll the text input to the beginning on blur? One thing that I will add is that Firefox' behavior appears to be inconsistent. Try, for example: 1. Visit http://jsfiddle.net/zeBsw/ 2. Enter "the quick brown fox jumps over the lazy dog. THE QUICK BROWN FOX JUMPS OVER THE LAZY DOG." into the first text box. 3. Press Tab to focus the second text box, then Shift+Tab to go back to the first text box. 4. Press the Left arrow key. Then press the Right arrow key enough times to position the caret after the first period char. Then type "abcdefg" (so, the value in the first text field is now "the quick brown fox jumps over the lazy dog.abcdefg THE QUICK BROWN FOX JUMPS OVER THE LAZY DOG."). 5. Press Tab again. Note that an ellipsis is drawn which cuts off the value. It seems that as long as the viewport of the control is not at the rightmost position, then the ellipsis will appear when tabbing away *if Firefox is already in the mode where an ellipsis is drawn*.
Note that we intentionally suppress the ellipsis in the editable control that has the caret so that the ellipsis doesn't obscure the text you're trying to edit. I'm guessing that's what you're seeing. The spec specifically allows for that behavior.
Hiding while the caret is in the text box/the text box has focus is fine. What I am seeing is that after the first text box loses focus after performing step (5) from the steps of Comment 3 above, the ellipsis is drawn. This seems inconsistent to me because when the text box loses focus after performing step (3) of the steps from the Description, an ellipsis is not drawn; i.e. there are some cases where an ellipsis is drawn on blur and others where the ellipsis is not drawn on blur.
The difference is that after step 3 in comment 0 the last character is in view -- there is no overflow. Showing an ellipsis in that case would not be compliant with the spec. The only reason Chrome is showing an ellipsis in that case is that they scroll to the start on blur and thereby make the text overflow.

I think I agree with comment 2... I'm not sure why this is particularly desirable, and why would it be inconsistent with textarea, where other browsers don't auto-scroll on blur?

(In reply to cetin from comment #7)

https://stackoverflow.com/questions/67055218/set-input-caret-position-on-blur-in-safari-without-refocusing-input

Why do you need to use setSelectionRange? input.scrollLeft = 0 achieves the same and shouldn't have non-layout side-effects I'd think.

Severity: normal → S3

I've just run into this behaviour, and I agree both that the current Firefox behaviour is inconsistent and leaving the end of the text showing rather than the beginning isn't the most sensible option.

Showing the beginning makes more sense

I think I agree with comment 2... I'm not sure why this is particularly desirable, and why would it be inconsistent with textarea, where other browsers don't auto-scroll on blur?

It's desirable because (assuming LTR language) we read from left to right. Consider a long filename:

"Company Report containing extra revisions for internal release v2"

Chrome will show us:

"Company Report"

Firefox will show:

"release v2"

Which leads the user to think either "I wonder what release of the company report this is (perhaps I should double check) vs "Oh it's release v2 of something, I wonder what?"

In general, the most valuable information in a field is likely to be on the left, because that's how humans communicate. We tend to transmit the most significant bits of information first. "Run away from the bears coming over the hill" vs "over the hill are coming bears which we should run away from"; survival favours those who hear the first sentence over the second.

We go from specific, to narrow, roughly speaking, and it is usually impossible to infer the context from looking at the end of a sentence.

Firefox's Inconsistent Behaviour

The current behaviour is also internally inconsistent.

Ellipsis in english are a visual signal that says "there is more content here than I can display".

Here's the logic in Chrome:

no ellipsis = "all content displayed here"
ellipsis = "this text continues to the right but I can't display it all in this space."

In Firefox

no ellipsis = "all content displayed here" OR it could mean "there is more content than I can display, and the last time you edited this field the cursor was in a position so that the content I can't display is to the left."

ellipsis = "there is more content here than I can display, and last time you edited this field the cursor was in a position such that the content I can't display is to the right"

Describing Chrome's behaviour is simpler, and it less confusing to the user.

In Firefox, the absence of an ellipsis doesn't tell us anything unless we remember the cursor position within the field.

The best way to resolve the ambiguity is to "scroll" the field to the left (actually, just show the beginning of the field when not focused).

In addition to that, setting text-overflow: ellipsis will also not work when not scrolled to the start of the text

You need to log in before you can comment on or make changes to this bug.