Page MenuHomePhabricator

Add reveal password action to mobile account creation form
Closed, ResolvedPublic3 Estimated Story Points

Description

This task builds on the account creation form cleanup (T409236) by adding a way for users to reveal their password while typing on the account creation form. Currently, the password field on mobile web has no reveal option, which makes it harder to catch typos - especially on mobile where the keyboard covers half the screen and mistyping is common.

A comparative analysis of the top 20 most visited websites (T410558) shows that password reveal is a near-universal pattern, implemented either as an inline icon within the input field or as a checkbox below it.

User story & summary:

As a new user creating an account on mobile web, I want to be able to reveal my password while typing so that I can verify what I've entered and avoid typos.

Design:

Scope: this task is scoped to Mobile only.

Figma designs

image.png (2,450×1,884 px, 479 KB)

Acceptance Criteria:

✅ AC1 - Default state

  • Given I am on the account creation page on mobile web
  • When I view the password field
  • Then the password input masks characters by default
  • And the reveal icon (cdxIconEye, open eye) is visible as endIcon prop, styled in @color-subtle

    ✅ AC2 - Reveal password
  • Given I have entered text in the password field
  • When I tap the reveal icon
  • Then the password characters become visible in plain text
  • And the icon fill color changes to @color-base, indicating the active state

    ✅ AC3 - Hide password
  • Given the password is currently revealed
  • When I tap the reveal icon again
  • Then the password characters are masked again
  • And the icon fill color returns to @color-subtle

    ✅ AC4 - Confirm password field
  • Given the account creation form includes a "Confirm password" field
  • When I interact with the confirm password field
  • Then the same reveal password behavior is available, with its own independent toggle state

    ✅ AC5 - State persistence
  • Given I have revealed the password
  • When I continue typing or interact with other fields
  • Then the reveal state persists until I explicitly tap the icon to hide it

    ✅ AC6 - Icon always visible
  • Given I am on the account creation page on mobile web
  • When I view the password field before entering any text
  • Then the reveal icon is visible (not contingent on the field having content)

    ✅ AC7 - Password helper text removed
  • Given I am on the account creation page on mobile web
  • When I view the password field
  • Then no helper text is displayed below the password input
Open questions:
  1. Which implementation pattern should we use? Two options from the comparative analysis (T410558):
    • End icon prop: Use the Codex TextInput component's end icon prop to display a show/hide icon inside the password field (see Figma: "reveal password - end icon prop")
    • Checkbox: Display a "Show password" checkbox below the password field (see Figma: "reveal password - checkbox")
      • Use endIcon prop
  2. If we go with the end icon approach, should the icon be visible before the user starts typing, or only appear once there's text in the field?
    • Visible before the user start typing
  3. If we go with the end icon approach, which icon represents the hidden (default) state? Two interpretations:
    • Icon shows available action: When the password is hidden, show cdxIconEye (open eye) to indicate "tap to reveal." When revealed, show cdxIconEyeClosed (eye with strikethrough) to indicate "tap to hide."
    • Icon shows current state: When the password is hidden, show cdxIconEyeClosed (eye with strikethrough) to indicate "this is currently hidden." When revealed, show cdxIconEye (open eye) to indicate "this is currently visible."
      • When the password is hidden, show cdxIconEye (open eye) set in @color-subtle to indicate "tap to reveal." When revealed, show cdxIconEye (open eye) set in @color-base to indicate the active state. Action is reversible: tapping again will hide the password.

Related Objects

Event Timeline

There are a very large number of changes, so older changes are hidden. Show Older Changes
KStoller-WMF moved this task from Product Backlog to Needs Refinement on the Growth-Team board.
KStoller-WMF set the point value for this task to 3.Mar 23 2026, 2:28 PM
Michael changed the task status from Open to Stalled.Mar 24 2026, 2:51 PM

Let's mark this stalled on finishing its subtask T421119: Add Icon support for text fields to HtmlForm

Michael changed the task status from Stalled to Open.Apr 9 2026, 10:12 AM
Michael claimed this task.
Michael moved this task from Incoming to Doing on the Growth-Team (FY2025-26 Q4 Sprint 1) board.

While the dependencies are not merged yet, let's move forward with creating this anyway with the assumption that the dependency is not going to be fundamentally blocked.

Change #1269543 had a related patch set uploaded (by Michael Große; author: Michael Große):

[mediawiki/extensions/WikimediaEvents@master] createAccount: Add password reveal functionality for experiment

https://gerrit.wikimedia.org/r/1269543

Change #1269543 merged by jenkins-bot:

[mediawiki/extensions/WikimediaEvents@master] createAccount: Add password reveal functionality for experiment

https://gerrit.wikimedia.org/r/1269543

AC7 - Password helper text removed

I think this acceptance criteria was missed? But otherwise I tested and other acceptance criteria is met.


@AAlhazwani-WMF @Michael
I know that it's not part of this task, but two other suboptimal aspects of the current password field that I noticed when testing, that I'm curious if we want to consider improving in the future:

  • we only show the password missmatch error after form submission. I assume the more ideal UX would be if we could show a warning immediately (and if it goes away once they match).
  • after receiving the error: "The passwords you entered do not match." upon submitting the form, the warning never goes away. Once I fix the error I'll see that warning until I submit the form again.

Screenshot 2026-04-28 at 5.23.10 PM.png (974×498 px, 68 KB)

AC7 - Password helper text removed

I think this acceptance criteria was missed? But otherwise I tested and other acceptance criteria is met.

correct we should remove the help text!

@AAlhazwani-WMF @Michael
I know that it's not part of this task, but two other suboptimal aspects of the current password field that I noticed when testing, that I'm curious if we want to consider improving in the future:

  • we only show the password missmatch error after form submission. I assume the more ideal UX would be if we could show a warning immediately (and if it goes away once they match).
  • after receiving the error: "The passwords you entered do not match." upon submitting the form, the warning never goes away. Once I fix the error I'll see that warning until I submit the form again.

Screenshot 2026-04-28 at 5.23.10 PM.png (974×498 px, 68 KB)

agree. we should validate on blur in addition to on submit. then on a second blur of a field that already has a warning or error, we should re-run validation and clear it if the field is now valid.

some other feedback, per AC1 and AC2 we should use the cdxIconEye for both reveal and hide. what changes is the fill color:

  • password field default state + empty field: icon color @color-placeholder
  • password field focus state + password hidden: icon color @color-subtle
  • password field focus state + password revealed: icon color @color-base
  • password field default state + filled field: icon color @color-base

agree. we should validate on blur in addition to on submit. then on a second blur of a field that already has a warning or error, we should re-run validation and clear it if the field is now valid.

@AAlhazwani-WMF - thanks for confirmation! I added:
T424979: Account Creation: improve password & confirm password field UX
Will you double-check the task and update the details if needed?

Change #1281523 had a related patch set uploaded (by Jforrester; author: Jforrester):

[mediawiki/extensions/WikimediaEvents@master] extension: Flag our new hard-dependency on TestKitchen

https://gerrit.wikimedia.org/r/1281523

I really like this idea, and hope it gets implemented and expanded to desktop, but I do have a general question about this. Some mobile browsers add their own version of this button (even without this change, i.e. Microsoft Edge on Android), how can we make sure that we hide the version provided by the mobile web browser? I have seen some poorly designed websites not hide the one injected by the browser which can lead to some weird design quirks regarding the password field.

Screenshot_20260501_111309_Edge.png (1,080×2,340 px, 174 KB)

Screenshot_20260501_111306_Edge.png (1,080×2,340 px, 175 KB)

Change #1281815 had a related patch set uploaded (by Gergő Tisza; author: Gergő Tisza):

[mediawiki/extensions/WikimediaEvents@master] Avoid making TestKitchen a hard dependency

https://gerrit.wikimedia.org/r/1281815

Change #1281523 merged by jenkins-bot:

[mediawiki/extensions/WikimediaEvents@master] extension: Flag our new hard-dependency on TestKitchen

https://gerrit.wikimedia.org/r/1281523

I really like this idea, and hope it gets implemented and expanded to desktop, but I do have a general question about this. Some mobile browsers add their own version of this button (even without this change, i.e. Microsoft Edge on Android), how can we make sure that we hide the version provided by the mobile web browser? I have seen some poorly designed websites not hide the one injected by the browser which can lead to some weird design quirks regarding the password field.

Screenshot_20260501_111309_Edge.png (1,080×2,340 px, 174 KB)

Screenshot_20260501_111306_Edge.png (1,080×2,340 px, 175 KB)

this is great observation - thanks for sharing this! it's definitely something that we should account for while implementing and testing with QA.

Etonkovidova subscribed.

for @AAlhazwani-WMF review

(1) By default, the input for passwords is masked, so the default icon is an eye icon crossed which makes sense (the design shows an open eye icon for masked input)

Screenshot 2026-05-11 at 8.07.46 PM.png (335×331 px, 32 KB)

(2) Some screenshots for quick review - no issues found:

masked input, not focusedmasked input, focusedrevealed input, focusedrevealed input, unfocused
Screenshot 2026-05-11 at 8.27.57 PM.png (350×511 px, 48 KB)
Screenshot 2026-05-11 at 8.07.39 PM.png (343×363 px, 33 KB)
Screenshot 2026-05-11 at 8.07.55 PM.png (348×365 px, 34 KB)
Screenshot 2026-05-11 at 8.27.08 PM.png (344×343 px, 30 KB)

(3) (answering https://phabricator.wikimedia.org/T419413#11869268)
There are few cases when a warning or error message is "stuck" - doesn't disappear when a user corrects the input. I'll review T424979 and either add specific cases to that task or file as a separate tickets. The unnecessary persistence of such messages is, technically, just a bug.

(4) on @Awesome_Aasim comment https://phabricator.wikimedia.org/T419413#11879648
Inserted password on Login form will be certainly tested when revealing password action will be added for Login workflow.

Change #1286344 had a related patch set uploaded (by Michael Große; author: Michael Große):

[mediawiki/extensions/WikimediaEvents@master] fix: differentiate password reveal icon by color instead

https://gerrit.wikimedia.org/r/1286344

some other feedback, per AC1 and AC2 we should use the cdxIconEye for both reveal and hide. what changes is the fill color:

  • password field default state + empty field: icon color @color-placeholder
  • password field focus state + password hidden: icon color @color-subtle
  • password field focus state + password revealed: icon color @color-base
  • password field default state + filled field: icon color @color-base

I can do that as written (and the new Gerrit change above does that), but that's not exactly what the AC say. And, it is probably still not what you want. Specifically: Interacting with the reveal-icon loses focus on the input. That's pretty unavoidable because the icon is a distinct element next to the input field, not inside it. We could set the focus back to the field, but that would lose your position inside of it and would move the focus to the end, which is arguably worse.

IMHO, the two different icons were more intuitive.

Change #1281815 abandoned by Gergő Tisza:

[mediawiki/extensions/WikimediaEvents@master] Avoid making TestKitchen a hard dependency

Reason:

Was officially declared a hard dependency in Ic218ee2c.

https://gerrit.wikimedia.org/r/1281815

i've met with @Michael and we've decided to simplify color management for the endIcon prop. we'll always use cdxIconEye as the icon, passed directly to the CSS-only CdxTextInput nested inside CdxField. for color, we're going to let the component's built-in opacity/fill definitions handle it rather than overriding anything ourselves.

Change #1288900 had a related patch set uploaded (by Michael Große; author: Michael Große):

[mediawiki/extensions/WikimediaEvents@master] fix: simplify to show only one icon type for password reveal

https://gerrit.wikimedia.org/r/1288900

Change #1286344 abandoned by Michael Große:

[mediawiki/extensions/WikimediaEvents@master] fix: differentiate password reveal icon by color instead

Reason:

We decided to go with If0ce5abd0eeac3ee42acd72d746c8dc91e19254f instead

https://gerrit.wikimedia.org/r/1286344

i've met with @Michael and we've decided to simplify color management for the endIcon prop. we'll always use cdxIconEye as the icon, passed directly to the CSS-only CdxTextInput nested inside CdxField. for color, we're going to let the component's built-in opacity/fill definitions handle it rather than overriding anything ourselves.

The new change should now implement this. Moving it to Code Review.

Change #1288900 merged by jenkins-bot:

[mediawiki/extensions/WikimediaEvents@master] fix: simplify to show only one icon type for password reveal

https://gerrit.wikimedia.org/r/1288900

Change #1289342 had a related patch set uploaded (by Michael Große; author: Michael Große):

[mediawiki/extensions/WikimediaEvents@wmf/1.47.0-wmf.3] fix: simplify to show only one icon type for password reveal

https://gerrit.wikimedia.org/r/1289342

Change #1289342 merged by jenkins-bot:

[mediawiki/extensions/WikimediaEvents@wmf/1.47.0-wmf.3] fix: simplify to show only one icon type for password reveal

https://gerrit.wikimedia.org/r/1289342

Mentioned in SAL (#wikimedia-operations) [2026-05-21T13:43:45Z] <lucaswerkmeister-wmde@deploy1003> Started scap sync-world: Backport for [[gerrit:1290743|composer.json: Updated symfony/yaml from 7.4.6 to 7.4.12 (T426861)]], [[gerrit:1289347|Skip init.test.js test if VisualEditor not installed (T426740)]], [[gerrit:1289342|fix: simplify to show only one icon type for password reveal (T419413)]]

Mentioned in SAL (#wikimedia-operations) [2026-05-21T13:45:28Z] <lucaswerkmeister-wmde@deploy1003> lucaswerkmeister-wmde, migr: Backport for [[gerrit:1290743|composer.json: Updated symfony/yaml from 7.4.6 to 7.4.12 (T426861)]], [[gerrit:1289347|Skip init.test.js test if VisualEditor not installed (T426740)]], [[gerrit:1289342|fix: simplify to show only one icon type for password reveal (T419413)]] synced to the testservers (see https://wikitech.wikimedia.org/wiki/Mwdebug). Changes

Mentioned in SAL (#wikimedia-operations) [2026-05-21T13:51:06Z] <lucaswerkmeister-wmde@deploy1003> Finished scap sync-world: Backport for [[gerrit:1290743|composer.json: Updated symfony/yaml from 7.4.6 to 7.4.12 (T426861)]], [[gerrit:1289347|Skip init.test.js test if VisualEditor not installed (T426740)]], [[gerrit:1289342|fix: simplify to show only one icon type for password reveal (T419413)]] (duration: 07m 20s)

i've met with @Michael and we've decided to simplify color management for the endIcon prop. we'll always use cdxIconEye as the icon, passed directly to the CSS-only CdxTextInput nested inside CdxField. for color, we're going to let the component's built-in opacity/fill definitions handle it rather than overriding anything ourselves.

The new change should now implement this. Moving it to Code Review.

The correct icons should now be verifyable on https://auth.wikimedia.org/enwiki/w/index.php?title=Special:CreateAccount&mpo=we-1-8-account-creation-form-v2%3Atreatment&mobileaction=toggle_view_mobile

thx, @Michael!

@AAlhazwani-WMF - moving to Design review for you to confirm the following UX.

Note: cdx-text-input__end-icon works as a toggle; doesn't provide an additional visual clue to whatever a password is revealed or not.

Default stateLight:
Screenshot 2026-05-22 at 2.59.04 PM.png (766×1,652 px, 196 KB)
Dark mode:
Screenshot 2026-05-22 at 2.24.59 PM.png (379×827 px, 76 KB)
Focused field stateLight mode:
Screenshot 2026-05-22 at 2.47.25 PM.png (380×841 px, 78 KB)
Dark mode:
Screenshot 2026-05-22 at 2.56.23 PM.png (760×1,660 px, 193 KB)
Reveal stateLight mode:
Screenshot 2026-05-22 at 2.52.07 PM.png (768×1,658 px, 185 KB)
Dark mode:
Screenshot 2026-05-22 at 2.25.40 PM.png (365×819 px, 71 KB)
Hidden stateLight mode:
Screenshot 2026-05-22 at 2.54.25 PM.png (742×1,660 px, 179 KB)
Dark mode:
Screenshot 2026-05-22 at 2.26.02 PM.png (376×838 px, 72 KB)
DMburugu subscribed.

This appears to be okay in production. In case there are issues, a follow up ticket can be filled.