LG-9050: Add password error handling

[jc-gsa]

🎫 Ticket

LG-9050

🛠 Summary of changes

This code changes password validation feedback when a user creates a new password for their account. The submit button is no longer disabled and error feedback is immediately applied. Please see the attached Figma for more information.

📜 Testing Plan

Create a new account. When entering a new password that is invalid please observe the changes in feedback.

[aduth]

I left a few comments, but functionally this appears to be working well 👍

[aduth]

This looks to be repeated from getStrength. Can we either remove the identical code from getStrength since the check happens here, or alternatively remove this code and update the call to validatePasswordField to pass strength as the argument below instead of z.score?

https://github.com/18F/identity-idp/blob/787e1da7029b131032b86d68de6f51856a98d707/app/javascript/packs/pw-strength.js#L136-L139

Also, if we did choose to keep this code, I think it's safe to assume that the password argument will always be a string, so we could simplify this and flatten the two conditions?

Suggested change

	// override the strength value to 2 if the password is < 12
	if (!(z && z.password.length && z.password.length >= 12)) {
	if (z.score >= 3) {
	z.score = 2;
	}
	if (password.length < 12 && z.score >= 3) {
	z.score = 2;

[jc-gsa]

I will make some changes. I refrained from modifying old code too much, as it provokes the question when do we just do a total rewrite of old code?

[aduth]

For a feature spec, I think Capybara's default locator methods are a bit more straight-forward to use, and also match the user's experience in their interaction with the content on the page.

Ideally, if we were wanting to test that the field is associated with a specific error message, we could use our custom have_description helper:

Suggested change

	message = find('input.password-toggle__input').native.attribute('validationMessage')
	expect(message).to eq t('errors.messages.stronger_password')
	expect(find(':focus')).to have_description t('errors.messages.stronger_password')

...but it looks like the have_description would need to a small revision to support use in feature specs:

diff --git a/spec/support/matchers/accessibility.rb b/spec/support/matchers/accessibility.rb
index 5a991666b..65f7bb687 100644
--- a/spec/support/matchers/accessibility.rb
+++ b/spec/support/matchers/accessibility.rb
@@ -98,3 +98,3 @@ RSpec::Matchers.define :have_description do |description|
       split(' ')&.
-      map { |descriptor_id| rendered.at_css("##{descriptor_id}")&.text }
+      map { |descriptor_id| page.find("##{descriptor_id}")&.text }
   end

As a fallback, we could test that the error content exists, and optionally is displayed as an error.

Suggested change

	message = find('input.password-toggle__input').native.attribute('validationMessage')
	expect(message).to eq t('errors.messages.stronger_password')
	expect(page).to have_content t('errors.messages.stronger_password')

Suggested change

	message = find('input.password-toggle__input').native.attribute('validationMessage')
	expect(message).to eq t('errors.messages.stronger_password')
	expect(page).to have_css('.usa-error-message', text: t('errors.messages.stronger_password'))

[aduth]

LGTM 👍