See also #2430375: Use HTML method of password autocomplete

I pulled the latest from Git. I am using Firefox 38.0.5 and the password is still present. Yes, JS is enabled.

CommentFileSizeAuthor
#4 fix_firefox-2513052-4.patch1.28 KBBWPanda
Support from Acquia helps fund testing for Drupal Acquia logo

Comments

NancyDru’s picture

Well, it may be working for a non-admin. Still looking.

NancyDru’s picture

Title: Not working » Not working in Firefox

This module is not clearing the password in Firefox (38.0.5). But it works fine in Chrome.

NancyDru’s picture

I changed $('#edit-pass1').attr('autocomplete', 'OFF').val(''); to $('#edit-pass1').val(''); and it is working now -- sometimes. I also tried IE9, Chrome, and Safari, and they all work.

According to https://developer.mozilla.org/en-US/docs/Web/Security/Securing_your_site..., the "autocomplete" option is deliberately ignored by all modern browsers.

BWPanda’s picture

Status: Active » Needs review
FileSize
1.28 KB

I'm also having this issue with Firefox but have found a solution: http://verysimple.com/2007/03/07/forcing-firefox-to-obey-autocompleteoff...

The author of that article proposes adding a new, hidden password field at the top of the form which the browser will autofill; meaning all other, normal password fields on the form are left blank.

This patch does just that for the user register form only (for testing). If it works and is accepted then a patch can be made that does the same thing for other forms too. It also keeps the javascript in place but changes it to act on the new password field instead as a backup.

NancyDru’s picture

How does this affect S.508 Accessibility compliance?

BWPanda’s picture

How does this affect S.508 Accessibility compliance?

I'm not sure, I'm not familiar with 'S.508 Accessibility compliance'...

NancyDru’s picture

About the Standards

There are specific requirements for hidden fields because they are not hidden to screen readers. It does not look like your patch takes that into account.