265159 - highlights the whole textbox even if input.setSelectionRange() is called onfocus

Status: NEW

(Core :: DOM: UI Events & Focus Handling, defect)

Description

[Dan Brown]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.0; rv:1.7.3) Gecko/20040913 Firefox/0.10
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.0; rv:1.7.3) Gecko/20040913 Firefox/0.10

When using the tab key to highlight an input field in a form for entry, when the
field gains focus, any text which is in the INPUT field becomes fully
highlighted even if a this is done:
this.form.inputName.setSelectionRange(x,y); range, or a range created via
this.form.inputName.createTextRange() in a function such as:

function setSelectionRange(input, selectionStart, selectionEnd)
{
	if (input.setSelectionRange)
	{
		input.focus();
		input.setSelectionRange(selectionStart, selectionEnd);


	} else if (input.createTextRange)
	{
		var range = input.createTextRange();
		range.collapse(true);
		range.moveEnd('character', selectionEnd);
		range.moveStart('character', selectionStart);
		range.select();
	}
}

If you simply click on the input field, the selection shows up correctly.

Reproducible: Always
Steps to Reproduce:
1. Go to: http://www.danbrown.ca/test/select.html
2. Tab until the INPUT field is highlighted.  The ENTIRE INPUT field is selected
even though the javascript event through onfocus() tells it to select only the
last two characters.
3. Make another window (or another tab) active, then switch back.  Only the last
two letters (as are supposed to initially) are selected.
4. Repeat step 1 above.
5. Click on the blank button.  The correct selection shows up.
6. Click somewhere on the page where neither the button nor INPUT have selection
or focus.
5. Click on the INPUT field, the correct selection shows up.

Actual Results:  
When tabbed into, the entire text in the INPUT text field is auto selected.

Expected Results:  
Only the last two digits of the date field should appear selected whenever the
INPUT field is tabbed onto, or clicked on initially with the mouse.

Comment 1

[Dan Brown]

maybe someone will actually look at the bug now.

Comment 2

[Csaba Gabor]

Thanks for the nice example Dan Brown.
Though I won't opine on whether it's a bug or not,
the following 1 line change works for me:

onfocus="window.setTimeout(function(x){return
function(){window.setSelectionRange(x, 8, 10);};}(this),10)"

Csaba Gabor from Vienna

Comment 3

[Dan Brown]

Well one would expect that if I used setSelectionRange() to set how much of a
field is highlighted when I focus on it in _any_ manner.  Your solution works
but I shouldn't have to add a hack nesting it in three functions when it
shouldn't take more than a single line call to do something so simple (and
shouldn't require a timeout).

Comment 4

[Gervase Markham [:gerv]]

This is an automated message, with ID "auto-resolve01".

This bug has had no comments for a long time. Statistically, we have found that
bug reports that have not been confirmed by a second user after three months are
highly unlikely to be the source of a fix to the code.

While your input is very important to us, our resources are limited and so we
are asking for your help in focussing our efforts. If you can still reproduce
this problem in the latest version of the product (see below for how to obtain a
copy) or, for feature requests, if it's not present in the latest version and
you still believe we should implement it, please visit the URL of this bug
(given at the top of this mail) and add a comment to that effect, giving more
reproduction information if you have it.

If it is not a problem any longer, you need take no action. If this bug is not
changed in any way in the next two weeks, it will be automatically resolved.
Thank you for your help in this matter.

The latest beta releases can be obtained from:
Firefox:     http://www.mozilla.org/projects/firefox/
Thunderbird: http://www.mozilla.org/products/thunderbird/releases/1.5beta1.html
Seamonkey:   http://www.mozilla.org/projects/seamonkey/

Comment 5

[Csaba Gabor]

I have tested this with a version that I downloaded last night (Deer Park Alpha
2:  Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9a1) Gecko/20051007
Firefox/1.6a1) and am confirming that the issue is still there.

Evidently, what happens is that when you tab into the control, there is a
subsequent section that decides it wants to select the entire thing.  But
whatever selection the default mechanism decides it wants, it should already
have happened, so that anything set in the onfocus has effect.  As the original
poster pointed out, this happens correctly when one clicks with the mouse.

Csaba Gabor from Vienna

Comment 6

[Nickolay_Ponomarev]

Attachment: testcase

Comment 7

[Nickolay_Ponomarev]

So the focus event fires, your handler gets executed, then the default handler
selects the whole textbox. Not sure if this is valid.

Comment 8

[Sean Hogan]

My experience:
If you click on the input then the setSelectionRange works as you would expect.  

If you tab to the input then the setSelectionRange seems not to work, but if you then CTRL-TAB (or ALT-TAB) away from the window and then back again you will find the range has been requested as you desired.  

How bizarre is that!? :)

My first-draft work-around is an event-handler on the keyup event.  The handler detects the keyup for the TAB key and then does the setSelectionRange.  

BTW
1. works fine in opera
2. preventDefault() makes no difference for either click-to-focus or tab-to-focus

Comment 9

[Mike Connor [:mconnor]]

So, we get some oddball events firing.  In opera, the testcase fires select, then focus.  We end up with focus, select, focus, seemingly.

This can be worked around via onselect="return false"

smaug, bz, jst, any ideas on this?

Comment 10

[Csaba Gabor]

Interesting alternating cycle.  If I bring up the attachment from comment 6, and then click in the first textbox, then there are two digits selected.  Now I click outside the textbox, and then I click in the textbox again.  This time the two digits are not selected.  If I now click outside the textbox, then in it again, the selection comes back.  Etc.

So I'm not exactly following these last few comments.  Isn't the issue whether or not the observed behaviour constitutes a bug, and if so fix it?  As opposed to offering a workaround (unless it's only a band aid till any fix, if there is one).

Comment 11

[Boris Zbarsky [:bzbarsky]]

Comment 7 is right on the money.  The relevant code in nsEventStateManager::ChangeFocusWith looks like:

3092   if (aFocusedWith != eEventFocusedByMouse) {
3093     MoveCaretToFocus();
3094     // Select text fields when focused via keyboard (tab or accesskey)
3095     if (sTextfieldSelectModel == eTextfieldSelect_auto &&
3096         mCurrentFocus &&
3097         mCurrentFocus->IsContentOfType(nsIContent::eHTML_FORM_CONTROL)) {

and this code runs after the SetContentState call that fires the "focus" event.

Ideally, we would handle selection from a system event group onfocus handler, or selecting before we fire the focus event (for IE compat?), or something...

Perhaps we should 

Comment 12

[David Bolter [:davidb] (NeedInfo me for attention)]

Mass un-assigning bugs assigned to Aaron.