This is a (mostly) straight port of the JavaScript in GOV.UK Publishing Components combined with the text input component, with some minor
alterations:

- JavaScript has been modified to fit the Design System's coding and documentation conventions.
- Support for configuration and localisation strings has been added.
- The function to move specific data-attributes has been omitted for the time being.
- Custom button styles have not been ported, instead using those from the Design System.
- Configuration options (via JS or data-attributes) haven't been hooked up just yet.

- Fix button appearing visually taller than the input
- Fix button changing size when text updated by setting a sensible flex-basis
- Fix button obscuring the input's focus style by adding a small space between the elements

Microsoft Edge provides its own mechanism for users to show and hide their password in the form of an eye icon within the input. (The feature is built into Chromium itself, however only Edge appears to use it for inputs on the web. Google Chrome only appears to use it in browser dialogs and in the settings area of the browser.)

We don't want to show this to our users. The button visually reproduces the functionality of our toggle, but in a way that we cannot syncronise with, thus it's possible for the two controls to present labelling that conflicts with the actual visibility of the password.

We can use a vendor-prefixed pseudo-element to hide the button in Edge, but this doesn't disable other functionality that is specific to Edge's implementation, like the Alt+F8 keyboard shortcut.

…tions

If a user filled out a password input and then navigated away from the page via a link, it is possible to use the browser back button to return to the page with the password field populated. It could then be viewed and copied using the show button. This could potentially be used by bad actors to obtain user passwords.

This code now blanks the input and resets the component state if the page is returned to, unless an explicit value has been set by the developer.

Athough we cannot guarantee complete safety in this scenario (as the attacker evidently has obtained some level of physical or remote access already), it may make this attack vector slightly more difficult to accomplish.

- `spellcheck` was being set as a string despite govukInput expecting it as a boolean.
- `autocapitalize` used the value 'off'. This appears to be a legacy value from the days it was specific to iOS, with 'none' being the newer, standardised value.

Possible return value from `document.querySelector()`

Helps JavaScript minifiers crunch this down more

If the user navigates back to the page through some means (back/forward buttons, reopening recently closed tab, etc.), re-hide the password if it's currently visible.

Discussions with the contributor previously revealed that this was added defensively 'just in case'. As far as we are aware it hasn't actually been used anywhere (both via anecdotal evidence and the only GitHub search results being spec tests), indicating it has little to no actual user need or demand.

In the interests of keeping things simple, we're going to remove this from our initial version.

This example allows us to test the password input in the context of signing into an existing account. This is in contrast to "update your account details", which requests a new password instead of asking for the current one.

The code for setting the aria-label was generating the keys `showAriaLabel` and `hideAriaLabel`. The keys are actually `showPasswordAriaLabel` and `hidePasswordAriaLabel` respectively.

Changes the aria-live attribute of the hidden status element from "polite" to "assertive".

This is intended to rectify an issue with VoiceOver on macOS, where the announcement would be spoken over by the changing text and aria-label of the toggle button. In this case, notifying the user that their password is visible (or not) feels like an important piece of information that should take priority.

Align with the style changes in #4843.

Co-authored-by: Romaric Pascal <romaric.pascal@digital.cabinet-office.gov.uk>

Testing a hypothesis that VoiceOver failing to read the aria-live consistently may be due to it only being added when a status is set for the first time.

If this is the case, then potentially it's also unnecessary to use assertive over polite.

…uppeteer-tests

Add Puppeteer tests for Password input