Disable autocompletion for email/password field when editing user profile

Needs to be fixed for Drupal 8 first

+++ b/modules/user/user.moduleundefined
@@ -1034,6 +1034,7 @@ function user_account_form(&$form, &$form_state) {
+	'#attributes' => array('autocomplete' => 'off'),

spacing error

Patch is looking good and reason is good.

Makes sense to me. Committed/pushed to 8.x, moving to 7.x for backport.

Assuming testbot will approve the patch, this is looking good.

I get it why we dont want autofill on password, yes but why the username? Neither the issue title nor the summary tells me.

If I understand correctly username is a problem if you create a new user, it gets filled with your own username, but you're right summary talks about email and new password, patch is indeed about email and username.

@jeff.maes can you clarify and change the summary?

Yeah, something seems wrong here - the patch does look like it changed username/e-mail only but didn't touch any of the password fields (contrary to the issue title). I really can't see why we would prevent autocomplete on anything but a password field.

Related issue: #787876: Edit "My Account" fills the first password field

The username/email mismatch is a separate problem that exists for a long time already. I just created an issue to fix that:

#2191785: Password managers are identifying/storing wrong username field when creating a user account

After noticing that in D8, my browser does not ask me to store my credentials at all anymore, I pickaxed the git log and found this issue.

The 'autocomplete=off' attribute seems to have been added to too many form elements here. Or perhaps more specifically, the changes were not limited to the case/condition of actually editing your own & existing user account.

As a result, the browser's autocompletion (+ password manager) is completely turned off for all incarnations of the user account form; i.e., in the registration form, the administrative user account creation form, the administrative edit form, and also the edit form.

Unless I misunderstood the purpose of this issue, the attribute should only have been added for the case of editing the own user account...

However, given the original topic starter, the committed change might have been unnecessary — the originally reported username/email autofilling mismatch is exactly what is being fixed in #2191785: Password managers are identifying/storing wrong username field when creating a user account

In light of that, I'm not sure whether we shouldn't roll back the patch in #3?

This is related #2219443: Autocomplete in Safari 7 overwrites email address on user profile edit form.

@sun, your patch https://drupal.org/files/issues/user.form_.22.patch addresses the username, but not the email.

$form['account']['mail'] = array(
      '#type' => 'email',
      '#title' => $this->t('E-mail address'),
      '#description' => $this->t('A valid e-mail address. All e-mails from the system will be sent to this address. The e-mail address is not made public and will only be used if you wish to receive a new password or wish to receive certain news or notifications by e-mail.'),
      '#required' => !(!$account->getEmail() && $user->hasPermission('administer users')),
      '#default_value' => (!$register ? $account->getEmail() : ''),
      '#attributes' => array('autocomplete' => 'off'),
    );

@David_Rothstein - the password field doesn't autocomplete anyways. Least not on my quick mobile testing. If this is happening in some smart phones then we should look at explicitly. I don't think it's a problem anywhere other than the username/email fields.

The revised/final patch in #2191785-25: Password managers are identifying/storing wrong username field when creating a user account now contains proper test coverage for this issue.

With this:

+    // Verify that autocomplete is off on all account fields.
+    foreach (array('mail', 'name', 'pass') as $key) {
+      $this->assertIdentical($form['account'][$key]['#attributes']['autocomplete'], 'off', "'$key' field: 'autocomplete' attribute is 'off'.");
+    }

I see no reason not to roll back the patch in #3.

Hm. The situation is a bit hairy. Technically, we could roll back the patch in #3 and redo it from scratch including tests, additionally accounting for the Safari issue in #15...

However, that would break #2191785: Password managers are identifying/storing wrong username field when creating a user account (which essentially reverts + re-implements already), so I'd personally prefer to simply move forward with that instead, and leave this issue for a possible backport only.

So confusing!! The patch in #3 was committed and Fixed in 2012, and subsequently re-opened much later to discuss reverting. This didn't happen and there has not been any discussion in many years so I'm going to re-mark this Needs work and bump to 7.x for backport.