453377 - [object HTMLInputElement].focus() does not set focus to the element

Status: RESOLVED FIXED

(Core :: Layout: Form Controls, defect)

Description

[[e-mail]]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.0.1) Gecko/2008070208 Firefox/3.0.1
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.0.1) Gecko/2008070208 Firefox/3.0.1

Calling the focus method of the file element should set focus to the element's browse button.  

Reproducible: Always

Steps to Reproduce:
1. Add an <input id=f1 type=file> element to the body
2. Call document.getElementById("f1").focus() in script

Actual Results:  
Focus is set to the document body.

Expected Results:  
Focus should be set to the element's Browse button.

Comment 2

[[e-mail]]

This isn't the same as bug 345195.  That bug detailed the problem of not being able to tab to a file element.  Bug 345195 has been fixed.  The problem outlined in this bug still remains.

Comment 3

[Vernon Nemitz]

I've run into a problem which has certain similarities to problems that are described in Bug 66900, Bug 212818, Bug 327102, Bug 362588, and this one.  For the moment I will hope that the similarities are sufficient that I need not create a new bug about it.

I'm using the Composer in SeaMonkey to construct some fairly simple web pages for a friend.  Frames were desired.  In this case the overall page has 3 frames, one horizontal across the top (for a permanent banner) and below it two columns, the left one being thin, for navigation stuff, and the right one for displaying different html pages.

A simple text input field is located in the left frame.  When the overall page is loaded, the input field receives the focus for the keyboard.  The user is requested to type something and then press the TAB key, which invokes the onChange event handler (the Enter key didn't work consistently across different browsers).

The JavaScript event-handling function takes the data from the input, tests its validity, and if its ok, uses it to load a page into the right-side frame.  Before the function ends, it attempts to return the keyboard focus to the input field, for the next data entry.  It also applys .select() so that the first keystroke can erase the prior entry, if the user desires (the user can of course use a cursor-arrow key to take away the select() and do an edit.)

For an example of what I mean by the above (a page that has no frames), look at
 http://www.nemitz.net/vernon/logicgam.htm
It is a small puzzle-game entirely written in client-side JavaScript, and the main data-entry field is controlled as described above, and works fine in most browsers.

On this other page that has frames, though, SeaMonkey does not succeed at applying the next keystroke to the input field, after the event-handler is done.  In IE it works perfectly.  I'll be trying FireFox tonight, to see what it does.

Some of the page-layout stuff I've described is located at http://www.vjmpublications.com (the left frame displays an "under construction" message).  I'm currently at a different computer and don't have access to post here, the code for the event handler.  Hopefully I've described it well enough that duplicating this issue will not be too troublesome.

The peculiar thing is that SeaMonkey can successfully select() the text in the input field.  If I use .focus() only, I see a blinking cursor.  But the next keystroke, after loading a page into the right-side frame, does not go into the input field; instead it is captured by the "finder" tool (looks for that letter in the displayed page; appears to be looking in the right-side frame).  I have to use the mouse to click the input field before keystokes start appearing there.  And disabling the finder tool doesn't work; the keystrokes just disappear into limbo.  I've spent several hours trying to focus() different things in stages, like the top window and then the left frame and then the input field, but nothing has yet worked.  (Except in IE, alas.)

The more-peculiar thing is what I first wrote about being able to direct keystrokes to that input field when the overall frameset page is first loads the subpages (using the onLoad event handler).  Why does it work then, and not after the other event handler loads a new file into the adjacent frame?

Comment 4

[Vernon Nemitz]

After more experimentation, I have some more information about this problem.  In one sense I found something I had done less-than-perfectly, which upon correcting allows the focus() to properly go to the input field in the left frame.  In another sense the question remains, "Why didn't it work like it worked in IE?"

The code for loading up a page in the right frame WAS something like this:
self.parent.RightSide.open("...") with correct stuff inside the parentheses, to ensure the the file loaded in the right-side frame.  Note that this code is being run from inside the left-side frame, in the JavaScript onChange event handler.  The code basically says, "Go to the right side frame and load a page into the right side frame."  That worked fine, but the problem was that the keyboard focus could not be made to return to the left-side frame.  Except in IE.  I tried FireFox and it has the same problem as SeaMonkey.

Code that works, however, for all three browsers, is something like this:  self.open("..."), without referencing the right-side frame outside of the parentheses.

So, as far as I'm concerned, there is still something of a bug, because I don't know why the first way to do it would so completely steal the keyboard focus --but at least I have a workaround for it.

Thank you.

Comment 5

[Aaron Leventhal]

I don't know how serious a regression it is, or when it broke, but it could affect some sites.

fileInput.focus() should focus the browse button.

Comment 6

[Neil Deakin]

This bug should have been fixed by 178324.