Thanks, that’s useful. Cheers.

Here’s something similar using jQuery — wipe all of the password fields on the page at once.

$().ready(function(){setTimeout(”$(’input[@type=password]‘).attr(’value’, ”);”, 100);});

thanks charles - i like that, nice and clean. i bet that code could be fairly easily ported to some other frameworks too - for people already including prototype, yui, etc, it could save some code.

> Setting value=”" is equally worthless because Firefox seems
> to populate this value just after the page is rendered.

…well: if Firefox somehow knows about some saved passwords (like when stored previously when autocomplete was not yet used) then it might still populate the password when the user enters the username. So: wait until page is loaded, wait some more, enter the user name and hit tab: voila, the password is there…

By the way: some folks want Firefox to offer the user the option to ignore the autocomplete setting: https://bugzilla.mozilla.org/show_bug.cgi?id=333080

Arjan.

hey arjan, that is a good point. i would say that 99% of the time this problem happens to me is on a “preferences” type of page where the user has the option to reset their password. But leaving the field blank keeps the password unchanged. Typically the user cannot change their username, so that doesn’t happen in my case - but i can see it is another situation to be aware of. It might be worth putting an onchange event in the username field to set the password to empty string.

As for the bug report - I would be happier if they added a an option to actually obey autocomplete consistently! I think the people who want auto-complete ignored might be unpleasantly surprised when they start seeing firefox change settings and such for them in random web applications. For example, auto-filling in their real email address on a public forum preference page. he he!

You don’t need the timeout if you’re using jQuery’s .ready() function:

jQuery(function($) { $(’input:password’).val(”) });

Another alternative (workaround that works 100% without jQuery)

It seems as if FF is looking for type=”password” to trigger the autosave password troll to activate.

So, why not prevent the save of the password to begin with…

(very rough example…)

function hideFromPassTroll(formObj, keycode)
{
if(keycode==13)
{
document.getElementById(’password’).value=document.getElementById(’field2′).value;
document.getElementById(’field2′).value=”";
document.getElementById(’field2′).type=”text”;
formObj.submit();
}
}

…continued…

form id=”loginform” action=”post”
input type=”text” id=”username” onKeyDown=”hideFromPassTroll(this.form,event.keyCode);”
input type=”password” id=”field2″ onKeyDown=”hideFromPassTroll(this.form,event.keyCode);”
input type=”button” id=”submit” value=”submit”
onClick=”hideFromPassTroll(this.form,event.keyCode);”
onKeyDown=”hideFromPassTroll(this.form,event.keyCode);”
input type=”hidden” id=”password”
form

Hey Nick, That seems to be a good idea too - If i understand, you’re using a hidden field for the real password and the visible password input is cleared onSubmit so that Firefox never receives the password - thus never saves it.

I hadn’t heard the term “password troll” before, he he, is that your own term?!

yeah, I figured it sounded more accurate than “autocomplete feature”.

I spent a few hours today trying to figure out how to trick FF and that’s what I came up with… seems to work reliably, but will require another method to set the “type” attribute for IE since it doesn’t seem to support direct access to it like I’ve used. I personally like that this method prevents the save in the first place.

Any simpler methods of doing this I wonder?

Ok, the simplest method that I could figure out, for changing the “field2″ type attribute of “password” to “text” is by killing off the entire “field2″ input.

So I wrapped the “field2″ HTML input element with a SPAN, then I modified things so that essentially:

formPassParentObj = document.getElementById(”field2″).parentNode;
formPassParentObj.innerHTML=”";

should now work in almost any browser that can modify innerHTML… maybe… probably… *shrugs*

[...] L’article sur VerySimple Dev Blog [...]