Disable autocomplete for browser saved password

[in-session]

Here there is a validation error if a password is stored and the register block is integrated as a modal.

Error:

jquery.validate.js:164 Uncaught TypeError: Cannot read properties of undefined (reading 'settings')
    at jQuery.fn.init.rules (jquery.validate.js:164:63)
    at $.<computed>.<computed>._calculateStrength (password-strength-indicator.js:75:42)
    at $.<computed>.<computed>._calculateStrength (widget.js:132:25)
    at HTMLInputElement.handlerProxy (widget.js:611:7)
    at HTMLInputElement.dispatch (jquery.js:5430:49)
    at elemData.handle (jquery.js:5234:47)

Code Reference:
https://developer.mozilla.org/en-US/docs/Web/HTML/Attributes/autocomplete#browser_compatibility

1. Create an account and save the password in Chrome/Mozilla
2. Then the registry page will show the password which is already filled

After the change this is no longer the case, a registration page should always use a new password.

[m2-assistant]

Hi @in-session. Thank you for your contribution
Here are some useful tips how you can test your changes using Magento test environment.
Add the comment under your pull request to deploy test or vanilla Magento instance:

• @magento give me test instance - deploy test instance based on PR changes
• @magento give me 2.4-develop instance - deploy vanilla Magento instance

❗ Automated tests can be triggered manually with an appropriate comment:

• @magento run all tests - run or re-run all required tests against the PR changes
• @magento run <test-build(s)> - run or re-run specific test build(s)
  For example: @magento run Unit Tests

<test-build(s)> is a comma-separated list of build names. Allowed build names are:

1. Database Compare
2. Functional Tests CE
3. Functional Tests EE,
4. Functional Tests B2B
5. Integration Tests
6. Magento Health Index
7. Sample Data Tests CE
8. Sample Data Tests EE
9. Sample Data Tests B2B
10. Static Tests
11. Unit Tests
12. WebAPI Tests
13. Semantic Version Checker

You can find more information about the builds here

ℹ️ Run only required test builds during development. Run all test builds before sending your pull request for review.

For more details, review the Magento Contributor Guide documentation.

⚠️ According to the Magento Contribution requirements, all Pull Requests must go through the Community Contributions Triage process. Community Contributions Triage is a public meeting.

🕙 You can find the schedule on the Magento Community Calendar page.

📞 The triage of Pull Requests happens in the queue order. If you want to speed up the delivery of your contribution, join the Community Contributions Triage session to discuss the appropriate ticket.

✏️ Feel free to post questions/proposals/feedback related to the Community Contributions Triage process to the corresponding Slack Channel

[in-session]

@magento run all tests

[magento-automated-testing]

The requested builds are added to the queue. You should be able to see them here within a few minutes. Please re-request them if they don't show in a reasonable amount of time.

[in-session]

@magento run WebAPI Tests

[magento-automated-testing]

The requested builds are added to the queue. You should be able to see them here within a few minutes. Please re-request them if they don't show in a reasonable amount of time.

[in-session]

I think failing tests are not related to changes from this PR

[sidolov]

@in-session could you please describe the steps to reproduce the issue? Thanks!

[in-session]

@sidolov

1. Create an account FE and save the password in Chrome/Mozilla
2. Logout
3. Then go to the registry page will show the password which is already saved in Chrome/Mozilla

The problem exists especially if you have a login tab popup on all pages and use the default block there. This then leads to validation errors.

[websuits]

Changing autocomplete from off to new-password is a good thing, but the fix won't solve the error from the screenshot. That error is caused by the fact that you probably have 2 templates with the same form ID. Changing the id from the custom template to another one (ex: "form-validate2") and applying the validation in that template to the new ID will fix that.