Password confirm field does not inherit #attributes attribute

I quite like the suggested approach at #33 of adding a dedicated key for the password_confirm attributes.

I've added a new patch that supports this, they now no longer inhertit the elements base #attributes, there is a new array key that can be passed called #pass2_attributes. Happy for feedback on the name. I called it this because the password confirmation form element is called #pass2, so this seemed the most consistent.

Reviewing #35 and also like the idea of using a 2nd variable.

Can the new solution approach be added to the issue summary.

For the remaining tasks will those have to happen after this is merged? Should they be follow ups?

+++ b/core/lib/Drupal/Core/Render/Element/PasswordConfirm.php
@@ -68,28 +68,38 @@ public static function valueCallback(&$element, $input, FormStateInterface $form
+      '#attributes' => is_array($element['#attributes']) ?
+      array_merge_recursive($element['#attributes'], $pass1_attributes) :
+      $pass1_attributes,

#pass1 inherits the attributes from the element. I'll update the IS and write a CR

Updated the existing CR - Ready for review

Fabulous, thanks @DanielVeza, that just leaves drafting/adding some documentation.

For anyone wishing to help with that, I'd say the @code example at the top of \Drupal\Core\Render\Element\PasswordConfirm is a good place to put a simple example, perhaps even a copy of the one in the change record.

Not the same issue, but could be related because are altering the same field.

Lets try to implement this a little more simpler by working with what we have, and not implementing brand new element properties.

This is a similar methodology to what you can do with checkboxes and/or radios to access the sub elements:

# Where `$form['account']['pass']` is the `password_confirm` element:
$form['account']['pass']['pass1']['#attributes']['class'] = ['foobar'];

We just need to update \Drupal\Core\Render\Element\PasswordConfirm::processPasswordConfirm to merge attributes from the passed render array, rather than override:

app/core/lib/Drupal/Core/Render/Element/PasswordConfirm.php:76

Old/current:

'#attributes' => [

Would change to:

'#attributes' => $element["pass1"]["#attributes"] ?? [] + [

Agree with the changes that @dpi suggested. Updating the title and the MR to reflect what the new solution will be.

Closed some issues that I think are duplicates, no credit to transfer. Also hiding files.

The latest version of the MR now has a dedicated form and test case for Password Confirm widgets, and the hook to modify the User Registration form has been removed.

Popped a review with some thoughts.

I think we need to decide the scope of this. Do we want to:

Allow specific attributes to be passed to the pass2 element.
OR
Allow the pass2 element to inherit the properties passed to the password_confirm element.

I'd vote for the 2nd, and maybe open a follow up for the first.

Whats others thoughts?

I would love pass2 to inherit the attributes of pass1 with an override capacity… but I suspect that will break a great many sites.
I’m not sure getting the pattern right in this instance is worth the pain we’re likely to cause for a small heap of intermediate site builders.

One change I added in the latest version of the MR is to give the attribute merging its own dedicated method PasswordConfirm::combineAttributes to merge the attribute arrays. This allows us to reuse the same merging code across both pass1 and pass2, but also to normalise the autocomplete attribute for both.

The reason why I think we have to normalise autocomplete is because the Nightwatch tests appeared to pick up a case via Axe where pass1 on the user edit form was invalid. After some investigation, I found that pass1 was rendering with the attribute autocomplete="off new-password", which appears to be invalid. To this end, I've tried to pick up the "off" value within either the array or string values of this attribute, and if it's found, reduce it to just autocomplete="off".

A good example of where this might be set is in \Drupal\user\AccountForm::form. This obviously makes handling attributes more complicated, and I'm wondering if this too is the right approach.