Closed
Bug 178520
Opened 22 years ago
Closed 22 years ago
input.focus() should not perform input.select()
Categories
(Core :: Layout: Form Controls, defect)
Core
Layout: Form Controls
Tracking
()
RESOLVED
FIXED
People
(Reporter: croo, Assigned: aaronlev)
References
(Blocks 1 open bug, )
Details
(Keywords: regression)
Attachments
(2 files)
2.24 KB,
patch
|
bryner
:
review+
bzbarsky
:
superreview+
asa
:
approval1.3a+
|
Details | Diff | Splinter Review |
517 bytes,
text/html
|
Details |
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.
Comment 1•22 years ago
|
||
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()
Updated•22 years ago
|
Status: UNCONFIRMED → NEW
Ever confirmed: true
OS: Windows XP → All
Hardware: PC → All
Comment 2•22 years ago
|
||
It certainly seems rotten not to have any way to do this. What do other browsers do?
Assignee | ||
Updated•22 years ago
|
Blocks: focusnav
Summary: input.focus() realy work as input.select() → input.focus() should not perform input.select()
Comment 3•22 years ago
|
||
*** Bug 181489 has been marked as a duplicate of this bug. ***
Comment 4•22 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.
Comment 5•22 years ago
|
||
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...
Reporter | ||
Comment 7•22 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.
Comment 8•22 years ago
|
||
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•22 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.
Comment 10•22 years ago
|
||
*** Bug 181743 has been marked as a duplicate of this bug. ***
Comment 11•22 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?
Comment 12•22 years ago
|
||
*** Bug 183482 has been marked as a duplicate of this bug. ***
Updated•22 years ago
|
Keywords: mozilla1.3,
regression
Assignee | ||
Comment 13•22 years ago
|
||
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•22 years ago
|
Attachment #108294 -
Flags: superreview?(bzbarsky)
Attachment #108294 -
Flags: review?(bryner)
Updated•22 years ago
|
Attachment #108294 -
Flags: review?(bryner) → review+
Comment 14•22 years ago
|
||
the patch is great. it makes typing in this test case work fine.
Updated•22 years ago
|
Attachment #108294 -
Flags: superreview?(bzbarsky) → superreview+
Updated•22 years ago
|
Attachment #108294 -
Flags: approval1.3a?
Comment 15•22 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•22 years ago
|
||
checked in
Status: NEW → RESOLVED
Closed: 22 years ago
Resolution: --- → FIXED
Comment 17•22 years ago
|
||
*** Bug 184740 has been marked as a duplicate of this bug. ***
Comment 18•22 years ago
|
||
*** 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.
Description
•