Implements UIs for the "create account" and "sign in" flows in brave://settings

[szilardszaloki]

Resolves brave/brave-browser#42508.

create_account_and_sign_in.mp4

Note: the tooltip and the corresponding regular expression-based password score implementation in the "create account" dialog have been removed in favor of getting the password strength from zxcvbn.

Known issues:

• The recommended approach to a Lit element's HTML template is to have it defined in an .html.ts file that's directly checked in to the repository, that is, no .html files are going through the html_to_wrapper target in the WebUI build pipeline. As such, the HTML template definition is lacking the <!--_html_template_start_--> and <!--_html_template_end_--> tags, without which the C++ templatizer does not do any text replacements — hence those tags are currently added manually.

TODOs:

• I suggest that we export noChange from third_party/lit/v3_0/lit.ts (which has been recently removed in Chromium due to deleting their only reference to it) and use it instead of the workaround that addresses a visual artifact in brave_account_create_dialog.html.ts.

Submitter Checklist:

• I confirm that no security/privacy review is needed and no other type of reviews are needed, or that I have requested them
• There is a ticket for my issue
• Used Github auto-closing keywords in the PR description above
• Wrote a good PR/commit description
• Squashed any review feedback or "fixup" commits before merge, so that history is a record of what happened in the repo, not your PR
• Added appropriate labels (QA/Yes or QA/No; release-notes/include or release-notes/exclude; OS/...) to the associated issue
• Checked the PR locally:
  • npm run test -- brave_browser_tests, npm run test -- brave_unit_tests wiki
  • npm run presubmit wiki, npm run gn_check, npm run tslint
• Ran git rebase master (if needed)

Reviewer Checklist:

• A security review is not needed, or a link to one is included in the PR description
• New files have MPL-2.0 license header
• Adequate test coverage exists to prevent regressions
• Major classes, functions and non-trivial code blocks are well-commented
• Changes in component dependencies are properly reflected in gn
• Code follows the style guide
• Test plan is specified in PR before merging

After-merge Checklist:

• The associated issue milestone is set to the smallest version that the
  changes has landed on
• All relevant documentation has been updated, for instance:
  • https://github.com/brave/brave-browser/wiki/Deviations-from-Chromium-(features-we-disable-or-remove)
  • https://github.com/brave/brave-browser/wiki/Proxy-redirected-URLs
  • https://github.com/brave/brave-browser/wiki/Fingerprinting-Protections
  • https://github.com/brave/brave-browser/wiki/Brave%E2%80%99s-Use-of-Referral-Codes
  • https://github.com/brave/brave-browser/wiki/Web-Compatibility-Exceptions-in-Brave
  • https://github.com/brave/brave-browser/wiki/QA-Guide
  • https://github.com/brave/brave-browser/wiki/P3A

Test Plan:

—

[github-actions]

The security team is monitoring all repositories for certain keywords. This PR includes the word(s) "password" and so security team members have been added as reviewers to take a look.

No need to request a full security review at this stage, the security team will take a look shortly and either clear the label or request more information/changes.

Notifications have already been sent, but if this is blocking your merge feel free to reach out directly to the security team on Slack so that we can expedite this check.

[brave-builds]

A Storybook has been deployed to preview UI for the latest push

[fallaciousreasoning]

Hey this looks great - I had a dig into _html_template_start_ - man, this is why we can't have nice things 😆

It's such an ugly way of solving it, it makes me sad 😆 Thanks upstream.

My only real comment is that we should use a mojo interface instead of a handler

[fallaciousreasoning]

out of interest, why would we need noChange here?

[szilardszaloki]

Basically, when there's a matching password in the password confirmation field, we show the checkmark and the text Passwords match. Now, if the user presses Cmd + Backspace on the text in the password confirmation field, we should just hide the dropdown and should not recalculate which icon or text to show — since the password confirmation field became empty, and there's nothing in there we should try to match against the field above. That's an edge-case here, but if we don't do anything, there's a visual artifact: the icon changes to the red triangle, while the text changes to Passwords don't match, and then the dropdown disappears — which looks rookie. 🙂

The proper way to handle that would be via signaling with noChange that we don't need a change in the DOM if this.passwordConfirmation.length === 0. Alternatively, there is this hack we have in brave_account_create_dialog.ts, but it's far from ideal, as the TS file is required to know about style-related stuff (i.e. name of icons).

[claucece]

This is looking awesome! Thank you @szilardszaloki !

[fmarier]

We'll need to update that since we are shipping accounts without support for Sync (for the time being).

[fmarier]

The self-custody option should not be there until we are ready to integrate with Sync.

[fmarier]

We don't need self-custody this for now.

[fmarier]

I don't think I saw it in this PR: does this include the gmail.con spellchecker or is that for a future PR?

[bridiver]

patch and browser/ui/BUILD.gn changes ok

[szilardszaloki]

I don't think I saw it in this PR: does this include the gmail.con spellchecker or is that for a future PR?

@fmarier Adding it to the current dropdown implementation introduces a visual artifact similar to the one being discussed here. Filed here for now — we'll likely want to export noChange from third_party/lit/v3_0/lit.ts to make our lives easier.

[bsclifton]

string reviewers ++

NOTE: I defer the content of the strings to @fmarier who has already left a comment 😄
But LGTM!

[fmarier]

I defer the content of the strings to @fmarier who has already left a comment 😄

Contents of the strings will need to change (as per my earlier comments) but since this is not enabled by default (and not translated) we can do that later as we get closer to enabling. So it's fine for now.

[github-actions]

[puLL-Merge] - brave/brave-core@26741

Description

This PR introduces a new Brave Account feature in the browser settings. It adds several new dialogs for account creation, sign-in, and password reset, as well as a new row in the "Get started" section of settings for managing the Brave account.

Changes

Changes

1. app/brave_settings_strings.grdp:

   • Added new localized strings for Brave Account UI elements.

2. browser/resources/settings/BUILD.gn:

   • Updated build configuration to include new Brave Account files.

3. browser/resources/settings/sources.gni:

   • Added new Brave Account related files to the build process.

4. browser/resources/settings/getting_started_page/:

   • Added several new files for Brave Account functionality:
     • brave_account_browser_proxy.ts
     • brave_account_common.ts
     • brave_account_create_dialog.ts
     • brave_account_dialog.ts
     • brave_account_entry_dialog.ts
     • brave_account_forgot_password_dialog.ts
     • brave_account_row.ts
     • brave_account_sign_in_dialog.ts
   • Added corresponding CSS files for styling.

5. browser/ui/BUILD.gn:

   • Added brave_account_handler.cc and brave_account_handler.h to the build.

6. browser/ui/webui/brave_settings_ui.cc:

   • Added BraveAccountHandler to the WebUI message handlers.

7. browser/ui/webui/settings/brave_account_handler.cc and brave_account_handler.h:

   • Implemented a new handler for Brave Account related WebUI messages.

8. browser/ui/webui/settings/brave_settings_localized_strings_provider.cc:

   • Added new localized strings for Brave Account UI elements.

9. ui/webui/resources/leo/web_components.ts:

   • Imported additional Leo web components (alert, icon, input).

sequenceDiagram
    participant User
    participant BraveSettingsUI
    participant BraveAccountHandler
    participant BraveAccountRow
    participant BraveAccountDialog

    User->>BraveSettingsUI: Open Settings
    BraveSettingsUI->>BraveAccountRow: Display Account Row
    User->>BraveAccountRow: Click "Get started"
    BraveAccountRow->>BraveAccountDialog: Show Entry Dialog
    User->>BraveAccountDialog: Choose Create Account
    BraveAccountDialog->>BraveAccountDialog: Show Create Account Dialog
    User->>BraveAccountDialog: Enter Account Details
    BraveAccountDialog->>BraveAccountHandler: Get Password Strength
    BraveAccountHandler-->>BraveAccountDialog: Return Password Strength
    User->>BraveAccountDialog: Submit Account Creation
    Note over BraveAccountDialog: Account Creation Logic (Not Implemented)
    BraveAccountDialog-->>BraveAccountRow: Update Account Status

Loading

Possible Issues

1. The implementation of actual account creation, sign-in, and password reset functionality is not included in this PR. These will need to be implemented separately.
2. There might be potential security considerations when handling user credentials that are not addressed in this PR.

Security Hotspots

1. brave_account_handler.cc: The GetPasswordStrength function handles password data. Ensure that this is done securely and that the password is not logged or stored inappropriately.

[brave-builds]

Released in v1.75.93