Userscripts.org

In the 3rd incarnation of this script, I have added new features and optimizations.

-Now works on sites that load everything through javascript (hotmail.com)
-Now works when websites try to turn off autocomplete in javascript after a regular form submit or javascript form submit (not ajax).

Thanks Joe Simmons for the optimizations.

Thanks Brade for mentioning that it doesn't work if a website disables it in javascript after a form submit. I've never run into a website like that but I was able to write a test case for it. In regards to your script, thanks for trying to tweak mine but yours will still be slower and run unnecessary code because greasemonkey scripts are always called in any html frame.

I have just released a 4th version of this script. This version fixes an issue that even I admit has been annoying but I haven't bothered to try to fix it until now.

You can now double click on the username form field to get autocomplete suggestions instead of clicking somewhere else and then double clicking on that field.

Apparently Firefox (and likely Seamonkey) needs to blur and focus a field after autocomplete is turned on. This may be a bug in the browser but this script now works around this issue by blurring and focus any text field where autocomplete was turned on. If autocomplete was set on the form instead of the form field, it will blur and focus every text field within that form field and stop with the first one in the form which is hopefully the username field (e.g. chaseonline.chase.com as of 2010-09-01).

Also Thanks David for providing swf examples of this problem.

I have just released the 5th version of this script. David did some QA on my script again and brought a few issues to my attention.

Previously the script was blurring and focusing all autocomplete fields but in the process, it was leaving the first field on an autocomplete=off form focused. This is fine for password forms but apparently there are other websites like Wikipedia that turn off autocomplete in forms that are not log in forms. As a result, these forms are focused which might cause user confusion because you cannot use the space bar or page up or page down keys since that search field is focused which is not the default behavior. In other sites that have autocomplete=off forms in the middle of a long scrolling page, this had the even worse effect of scrolling to that position as a result of focusing that field.

As a result, I have fixed this bug and added a new feature:

-When focusing and blurring, the default behavior is to end with a blur instead of a focus. Since this still effects the scroll position, the scroll position is then reset back to the scroll position that the user was at when the execution of this script started. The user might notice a slight flicker due to to the scroll position being returned to original user set scroll position.
-Since focusing and blurring autcomplete related input fields messes with the tab position, the first time the user presses the tab key, the user can expect one of two behaviors:

1. If the script detects a password input field on the page, the first time the user presses the tab key, the script will focus the cursor on the first text input field it sees in that first password form which likely has the effect of focusing on the username input field of a username/password input form.
2. If the script does not detect a password input field on the page, the first time the user presses the tab key, the script will focus on the first element in the document that it can focus on which is the default browser behavior.

Thanks again for your help David.

In the 6th version of this script, I fixed an issue where the browser was not returning to the originating scroll position correctly due to the lack of a document type definition. So this fix should take care of all that tag soup out there like 4chan.org as well.

Thanks Christopher for pointing this out.