Form data associated with the credentials, including "displayUser" and "displayHost"

A custom implementation should include this information in the information message it displays to the user, to allow the user to make an informed acceptance or rejection decision.

For example formData["displayUser"] will contain the username associated with the credentials, and formData["displayHost"] will contain the name of the site for which the credentials are valid.

If the notificationType is set to "password-update-multiuser" then there are multiple potential usernames associated with the password being updated and the engine doesn't know which to update. In this case formData will include the usernames key containing an array of username. These should be presented to the user to allow them to select which username to update.

The gecko localization key of the message to display to the user

A custom implementation can use this information to tailor the message and details supplied to the user.

The value is either a string or an array. If it's an array then the first value will be the gecko localization key taken from the commonDialogs.properties file. The remaining items in the array are the parameter values to replace %1, %2, etc. in the string.

If the value is a string then it will be a gecko localization key without parameters.

You can search the Firefox Pontoon localization database for this file, followed by the appropriate key.

The key can be one of the following values:

• updatePasswordMsg
• updatePasswordMsgNoUser
• rememberPasswordMsg
• rememberPasswordMsgNoUsername
• passwordChangeTitle

Care must be taken as it's possible these values may change with future engine updates.

The type of password operation being requested for the site

The value will be one of "password-save" (if the credentials have not been seen before; the user should be asked whether they wish the webview to store the credentials for them), "password-update" (if the credentials have changed; the user should be asked whether they wish the webview to update the stored version of the credentials) or "password-update-multiuser" (if the password is being updated but there are multiple potential logins and the user must choose the correct one to update).

A custom implementation should display a different information message to the user, depending on the value of this property, to allow the user to make an informed acceptance or rejection decision. The AuthPopupInterface::messageKey(messageKey} localization key will be set to a message relevant for the dialog type.

This signal is emitted by the popup if the user accepts the prompt

The custom implementation must emit this signal when the user triggers the acceptance action (e.g. a button or navigation action which the user can trigger to allow the web view to store the credentials on their behalf).

After emitting this signal, the popup should perform an appropriate transition to make itself invisible and non-interactable (e.g. for an item-derived popup, an animated opacity transition, and then setting visible to false once the animation is complete).

This signal is emitted by the popup if the user rejects the prompt

The custom implementation must emit this signal when the user triggers the rejection action (e.g. a button or navigation action which the user can trigger to disallow the web view from storing the credentials on their behalf).

After emitting this signal, the popup should perform an appropriate transition to make itself invisible and non-interactable (e.g. for an item-derived popup, an animated opacity transition, and then setting visible to false once the animation is complete).