Disabling Safari autofill on usernames and passwords

Question

You might already know, that Safari has a nasty autofill bug where it fills email, username and password fields no matter if you set autocomplete=\"off\" or not

Answer 1

After scanning through Apple's Safari HTML pages and not finding anything on auto complete, I did some searching and thinking.

After reading a (mildly) related question on Apple discussions, I remembered that the default is to not allow remembered passwords, etc (which can be enabled in iDevice system settings, or at the prompt). Since Apple has moved this feature out of the browser and into their (proprietary, i)OS (screen shots on this article), I believe they are ignoring the HTML form/field property entirely.

Unless they change their mentality as to this feature, as I'm sure this is their expected behavior, on their locked down devices, I would work under the assumption that this isn't going away. This is probably different for native iOS apps. Definitely keep the form autocomplete="off" and hopefully they'll one day get back to the HTML5 standard for the feature.

I know this doesn't include any work around, but I think if you come to terms with it being a non-browser 'feature' on iDevices, it makes sense (in an Apple kind of way).

Answer 2

The reason browsers are ignoring autocomplete=off is because there have been some web-sites that tried to disable auto-completing of passwords.

That is wrong.

And in July 2014 Firefox was the last major browser to finally implement the change to ignore any web-site that tries to turn off autocompleting of passwords.

• June 2009: IEInternals blog where they discuss keeping the user in control (archive)
• February 2014: Chrome's announcement when they began ignoring autocomplete=off (archive)
• January 2014: Bugzilla Bug 956906 - ignore autocomplete="off" when offering to save passwords via the password manager (archive)
• Reddit discussion (archive)

One of the top user-complaints about our HTML Forms AutoComplete feature is “It doesn’t work– I don’t see any of my previously entered text.” When debugging such cases, we usually find that the site has explicitly disabled the feature using the provided attribute, but of course, users have no idea that the site has done so and simply assume that IE is buggy. In my experience, when features are hidden or replaced, users will usually blame the browser, not the website.

Any attempt by any web-site to circumvent the browser's preference is wrong, that is why browsers ignore it. There is no reason known why a web-site should try to disable saving of passwords.

• Chrome ignores it
• Safari ignores it
• IE ignores it
• Firefox ignores it

At this point, web developers typically protest “But I wouldn’t do this everywhere– only in a few little bits where it makes sense!” Even if that’s true, unfortunately, this is yet another case where there’s really no way for the browser to tell the difference. Remember, popup windows were once a happy, useful part of the web browsing experience, until their abuse by advertisers made them the bane of users everywhere. Inevitably, all browsers began blocking popups, breaking even the “good” sites that used popups with good taste and discretion.

What if I'm a special snowflake?

There are people who bring up a good use-case:

I have a shared, public area, kiosk style computer. We don't want someone to (accidentally or intentionally) save their password so the next user could use it.

That does not violate the statement:

Any attempt by any web-site to circumvent the browser's preference is wrong

That is because in the case of a shared kiosk:

• it is not the web-server that has the oddball policy
• it is the client user-agent that has the oddball policy

The browser (the shared computer) is the one that has the requirement that it not try to save passwords.

The correct way to prevent the browser from saving passwords
is to configure the browser to not save passwords.

Since you have locked down and control this kiosk computer: you control the settings. That includes the option of saving passwords.

In Chrome and Internet Explorer, you configure those options using Group Policies (e.g. registry keys).

From the Chrome Policy List:

AutoFillEnabled

Enable AutoFill

Data type: Boolean (REG_DWORD)

Windows registry location: Software\Policies\Chromium\AutoFillEnabled

Description: Enables Chromium's AutoFill feature and allows users to auto complete web forms using previously stored information such as address or credit card information. If you disable this setting, AutoFill will be inaccessible to users. If you enable this setting or do not set a value, AutoFill will remain under the control of the user. This will allow them to configure AutoFill profiles and to switch AutoFill on or off at their own discretion.

Please pass the word up to corporate managers that trying to disable autocompleting of password is wrong. It is so wrong that browsers are intentionally ignoring anyone who tries to do it. Those people should stop doing the wrong thing.™

Put it another way

In other words:

• if the users browser
• mistakes "Please enter the name of your favorite maiden name's first color." for a new password
• and the user
• doesn't want their browser
• to update their password,
• then they
• will click Nope

• if i want to save my HIPPA password: that's my right
• if i want to save my PCI password: that's my right
• if i want to save the "new password for the user": that's my right
• if i want to save the one-time-password: that's my right
• if i want to save my "first color's favorite maiden" answer: that's my right.

It's not your job to over-rule the user's wishes. It's their browser; not yours.

Answer 3

Fix: browser autofill in by readonly-mode and set writable on focus

 <input type="password" readonly onfocus="this.removeAttribute('readonly');"/>

(focus = at mouse click and tabbing through fields)

Update: Mobile Safari sets cursor in the field, but does not show virtual keyboard. New Fix works like before but handles virtual keyboard:

<input id="email" readonly type="email" onfocus="if (this.hasAttribute('readonly')) {
    this.removeAttribute('readonly');
    // fix for mobile safari to show virtual keyboard
    this.blur();    this.focus();  }" />

Live Demo https://jsfiddle.net/danielsuess/n0scguv6/

// UpdateEnd

Explanation: Browser auto fills credentials to wrong text field?

Ok, you just noticed that:

Safari autofill kicks in. No matter [what the fields are named] @Jari

and there's an assumption that:

Safari seems to look for an input field with password and username and always tries to fill it @user3172174

Sometimes I notice this strange behavior on Chrome and Safari, when there are password fields in the same form. I guess, the browser looks for a password field to insert your saved credentials. Then it autofills username into the nearest textlike-input field , that appears prior the password field in DOM (just guessing due to observation). As the browser is the last instance and you can not control it,

sometimes even autocomplete=off would not prevent to fill in credentials into wrong fields, but not user or nickname field.

This readonly-fix above worked for me.

Answer 4

You can try this variant. It works for me. If you change field value once, Safari will change it again. If user clicked at this field, after this the value wouldn't be changed by Safari automatically.

  $.browser.chrome = /chrome/.test(navigator.userAgent.toLowerCase());
        if($.browser.chrome){
            $.browser.safari = false;
        }

        var isChanged=false;

        $('#Email').change(function () {
            if ($.browser.safari && !isChanged) {
                $('#Email').val('@Model.Email');
            }
        });

        $('#Email').click(function () {
            if ( $.browser.safari && !isChanged) {
                isChanged = true;
            }
        }); var isChangePassword = false;
    $('#OldPassword').change(function () {
        if ($.browser.safari && !isChangePassword) {
            $('#OldPassword').val('');
        }
    });

    $('#OldPassword').click(function () {
        if ($.browser.safari && !isChangePassword) {
            isChangePassword= true;
        }
    });

Answer 5

My issue: I have a section in an admin area that allows users to set all language values, some of which contain the words "password", "email", "email address" etc. I don't want these values to be filled with the user's details, they are for creating translations into another language. This is then a valid exception to the "circumvent the browser's preference" mentioned.

My solution: I simply created alternate names:

$name = str_replace('email','em___l',$name);
$name = str_replace('password','pa___d',$name);

<input type="text" name="<?=$name?>" id="<?=$name?>" />

Then when the form is posted:

foreach($_POST as $name=>$value) {
    $name=str_replace('em___l','email',$name);
    $name=str_replace('pa___d','password',$name);
    $_POST[$name]=$value;
}

This is the only method that worked for me.

Answer 6

I have also been bitten by Safari's weird default autocomplete behaviour, but rather than completely disable it, I managed to make it work for me by following the guidelines at https://www.chromium.org/developers/design-documents/form-styles-that-chromium-understands.

Specifically, I put autocomplete="username" on the username field and autocomplete="password-current" on the password field. This tells the browser which fields to autofill, rather than having it guess, and it fixed autocomplete for my use case.

This approach works for both "email first" login forms (password field not immediately visible, eg Google login) as well as conventional login forms with both username and password fields visible.