325021 - (FormAutofocus) Automatically focus first textbox if I start typing

Status: REOPENED

(Core :: Layout: Form Controls, enhancement)

Description

[nillenator]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8) Gecko/20051111 Firefox/1.5
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8) Gecko/20051111 Firefox/1.5

When browsing to pages with forms, you need to 
manually place the focus in a input box.
It would be nice if this could be done automatically.


Reproducible: Always

Steps to Reproduce:
1. Point you browsrer to a page with forms
2. Begin typing, fill in your name, for example
3. Text doesn't appear in the textbox

Actual Results:  
Input doesn't appeare anywhere.

Expected Results:  
Input should  appear in the first text box (input box) available on the page.

This is a nice-to-have feature request.

Comment 1

[Jesse Ruderman]

I kinda like this idea.  Most search engines automatically focus the textbox, but:

* Most only do so onload (after all images have finished loading), which isn't very convenient.  (See also bug 226386.)  

* http://www.yahoo.com/ does not, presumably because there is non-search stuff on the page you might want to scroll to.

* http://www.bittorrent.com/ does not, for no discernable reason.

* http://www.live.com/ does this using JavaScript, which is nice because it lets you scroll the page or type a search without managing focus yourself.  Cmd+V to paste doesn't automatically focus the live.com textbox, though.

Adding this feature would require re-wording the auto-find-as-you-type pref.

Comment 2

[Jesse Ruderman]

Confirming -- this doesn't seem to be a dup.

See also bug 144144, "[RFE] Pages with only 1 textbox should focus that textbox automatically".  That bug was wontfixed for reasons that don't apply here.

Comment 3

[Jo Hermans]

Wouldn't this conflict with find-as-you-type ?

Comment 4

[Matthew T (active 1999-2002)]

In Firefox, Safari, Opera, and Internet Explorer, I can reliably focus the first text field in any page by pressing Tab once (unless the page focuses an element using script), because those browsers follow the standard Mac behavior of Tab navigating only between text fields and listboxes. This is very convenient; when I'm using the keyboard I'm much more interested in typing stuff than in traversing links. In OS X this is controlled by the "Full keyboard access" preference, which currently has no counterpart on other platforms: Windows, Gnome, and KDE always use the tabbing mode that OS X offers for disabled people. So perhaps Firefox on other platforms could present an equivalent option in "Advanced" > "General" > "Accessibility".

Comment 5

[Jesse Ruderman]

This would only conflict with find-as-you-type when auto-find-as-you-type is enabled. So I guess this feature would be disabled when auto-find-as-you-type is enabled.

Pressing Tab isn't ideal if the page is going to call focus() onload.  If your timing is off, you'll end up focusing the next thing in the tab order *after* the textbox you wanted to type into.

Comment 6

[Dave Townsend [:mossop]]

Thinking about this, with my admittedly rudimentary knowledge of the focus handling, I think that the idea here is that after all load events have happened, to focus the first textbox, if the webpage itself has focus.

That is to say that if a specific element has focus then that doesn't change, and if a chrome area has focus (url bar, search bar etc) then that doesn't change.

Applying the same logic to the handling of focus calls would I guess resolve bug 226386.

Comment 7

[Jesse Ruderman]

We don't want to move focus completely automatically, without the user typing -- that would run into the problems described in bug 144144.  We also don't want to wait until the page finishes loading; that would be annoying.

Comment 8

[Matthew T (active 1999-2002)]

The problem with tabbing and script changing focus near-simultaneously could be resolved by having tabbing change focus not necessarily to the adjacent focusable element, but to what *would* have been the next/previous focusable element if script hadn't changed focus in the past ~0.5 seconds. (That might require leaving some sort of highly buoyant "focus was here" marker in the DOM, so an appropriate element is chosen even if large parts of the DOM are deleted in the meantime.) But even without such minutiae, the Tab approach is very useful in multiple shipping browsers, making it a viable alternative to the approach described in comment 0.

Comment 9

[Aaron Leventhal]

WONTFIX for the reason's Jesse explained.

Comment 10

[Jesse Ruderman]

Huh?  I didn't suggest WONTFIXing this; in fact, I kinda supported fixing it.

Comment 11

[Aaron Leventhal]

This was fixed in trunk sometime last year but we didn't want to take any more risky focus fixes for Firefox 1.5. You'll have to wait until Firefox 3 for the fix. Not sure what the bug # was. You can get a test trunk build here:
http://ftp.mozilla.org/pub/mozilla.org/firefox/nightly/latest-trunk/

Comment 12

[Aaron Leventhal]

Sorry, that comment was meant for a different bug.

Comment 13

[Aaron Leventhal]

Now that I've had time to look, I don't see a real problem with doing this. Might be nice. Could be good extension fodder too.

Comment 14

[Thomas Bertels]

I'd suggest to disable it when search-as-I-type is enabled.