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
It certainly seems rotten not to have any way to do this. What do other browsers do?
Summary: input.focus() realy work as input.select() → input.focus() should not perform input.select()
*** Bug 181489 has been marked as a duplicate of this bug. ***
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
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.
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. ***
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
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=
Attachment #108294 - Flags: review?(bryner) → review+
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+
Attachment #108294 - Flags: approval1.3a?
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+
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.