input.focus() should not perform input.select()

RESOLVED FIXED

Status

()

--
major
RESOLVED FIXED
16 years ago
16 years ago

People

(Reporter: croo, Assigned: aaronlev)

Tracking

(Blocks: 1 bug, {regression})

Trunk
regression
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

(URL)

Attachments

(2 attachments)

(Reporter)

Description

16 years ago
User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.2b) Gecko/20021105
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.2b) Gecko/20021105

Well. I think it is wery upset -- there is no way to do a focus to input text
without text to be selected. Following example created to show bug:

<form name="ThisForm">
  <input type="text" name="input_box" value="Entered text" size=55>
  <input type="button" value="Focus"
onClick=document.forms["ThisForm"].input_box.focus()>
  <input type="button" value="Select"
onClick=document.forms["ThisForm"].input_box.select()>
</form>

Actions of buttons should be different, but they are same.

Reproducible: Always

Steps to Reproduce:
1.Open http://www.stabes.nm.ru/Music.html
2.Click on "Focus" button to check that it do select() of input text
3.Click outside of text area to lost focus and clicl "Select" button

Actual Results:  
result of focus() and select() functions are the same

Expected Results:  
focus() should not select text in input area

This bug is not shown in Mozilla 1.0.0 under Linux from Debian distibution.
This was done on purpose, but I'm not sure the goal was to have .focus() from
user JS also perform a .select() (though it may have been).
Assignee: jst → form
Component: DOM Level 0 → Layout: Form Controls
QA Contact: desale → tpreston
Summary: window.focus() realy work as window.select() → input.focus() realy work as input.select()
Status: UNCONFIRMED → NEW
Ever confirmed: true
OS: Windows XP → All
Hardware: PC → All

Comment 2

16 years ago
It certainly seems rotten not to have any way to do this.  What do other
browsers do?
(Assignee)

Updated

16 years ago
Blocks: 83552
Summary: input.focus() realy work as input.select() → input.focus() should not perform input.select()

Comment 3

16 years ago
*** Bug 181489 has been marked as a duplicate of this bug. ***

Comment 4

16 years ago
with IE 6, the buttons do 2 completely independant things:
- 'focus' moves the cursor to the left of the first character in the input.
- 'select' selects all the text and doesn't have a cursor (if you move left, the
cursor is to the left of the first character, if you move right, the cursor is
to the right of the last character.)

this bug causes problems in mozilla on pages that have a body
onload="form.input.focus();" because if you're typing when onload fires, you
lose all your input. 
OK.  I think one way to do this is that .focus() should focus the field and
select it _unless_ the field already has focus.  Then it should be a no-op. 
That should at least not select() the textfield you are currently typing in....
(we have bugs on that too; can't find the bug#s right now).

The other option is to differentiate clicking a text input from calling focus()
on it (and maybe have to differentiate whether focus() is called from chrome or
content too?  not sure what chrome expects here).

Notice that the comments in the patch for bug 28583 suggest that this bug is
_not_ an intended consequence...
This is aaron's.
Assignee: form → aaronl
(Reporter)

Comment 7

16 years ago
Just one thing should be added. Right now there is no way to do a js deselect --
so if focus() call a select() then it would not possible to made an unselected
focus (well, I could think about hard-coded event emulation). So js focus()
should be different from chrome focus(). Other way is to add a non-standart
deselect() method for input.
chrome is written in JS.  So the deal with making chrome and content behave
differently (if we want to) will involve looking at the security context of the
JS in the usual way.

Comment 9

16 years ago
IE actually does a pretty cool thing that may be required to get focus() to not
interfere with your text while typing:  it remembers the cursor location.  it
seems to clear the location when the document has the focus.  so if you have
"text" in an input, and the cursor is between the 'e' and the 'x', focus() will
always put the cursor in the same spot unless you click on an empty area of the
document.  at that point it puts the cursor at the 0th position of the input.

I bring this up because if mozilla's focus() always puts the cursor at the 0th
position, searching amazon for "Simpsons" will result in a search for "psonsSim"
if you are typing when body.onload fires.
*** Bug 181743 has been marked as a duplicate of this bug. ***

Comment 11

16 years ago
I cannot tell you people how many times my Google searches or Excite email
password entry get messed up now because of this bug.  Any progress?
*** Bug 183482 has been marked as a duplicate of this bug. ***
Keywords: mozilla1.3, regression
(Assignee)

Comment 13

16 years ago
Created attachment 108294 [details] [diff] [review]
The textfield should get selected when moved to via kbd, not from mouse click or .,focus() call

My mistake -- I originally thought it should get selected as long as it wasn't
focused via the mouse. Moving this into ChangeFocus() avoids calls that come
from script.

Seeking r=/sr=
(Assignee)

Updated

16 years ago
Attachment #108294 - Flags: superreview?(bzbarsky)
Attachment #108294 - Flags: review?(bryner)
Attachment #108294 - Flags: review?(bryner) → review+

Comment 14

16 years ago
Created attachment 108305 [details]
a testcase for field focusing

the patch is great.  it makes typing in this test case work fine.
Attachment #108294 - Flags: superreview?(bzbarsky) → superreview+

Comment 15

16 years ago
Comment on attachment 108294 [details] [diff] [review]
The textfield should get selected when moved to via kbd, not from mouse click or .,focus() call

a=asa for checkin to 1.3a
Attachment #108294 - Flags: approval1.3a? → approval1.3a+
(Assignee)

Comment 16

16 years ago
checked in
Status: NEW → RESOLVED
Last Resolved: 16 years ago
Resolution: --- → FIXED
*** Bug 184740 has been marked as a duplicate of this bug. ***
*** Bug 180767 has been marked as a duplicate of this bug. ***
You need to log in before you can comment on or make changes to this bug.