1893284 - Consider making the Login Password Field a shared reusable component

Status: NEW

(Firefox :: about:logins, task)

Description

[Mike Conley (:mconley) (:⚙️)]

The profile backup project will require users to provide a strong password in order to encrypt their backups. Our Figma specification calls for password inputs that have reveal buttons, similar to the password inputs available in about:logins.

Speaking with Victoria, our UX designer, she has no issue with us re-using the same look and feel as about:logins for these password inputs.

Those inputs currently live at https://searchfox.org/mozilla-central/rev/6121b33709dd80979a6806ff59096a561e348ae8/browser/components/aboutlogins/content/components/input-field/login-password-field.mjs. There appears to be a dependency on input-field.mjs and input-field.css.

So my question to the about:logins team, and the broader reusable components team, is whether or not we'd consider trying to uplift the existing login-password-field.mjs into a widget under toolkit/content/widgets? If so, what would the process be to do such a thing?

Comment 1

[Sergey Galich [:serg]]

I'd recommend to have Bug 1743046 finished, so we won't need custom components for reveal/conceal of password inputs.

Comment 2

[Mike Conley (:mconley) (:⚙️)]

While we wait for bug 1743046 to be addressed, I wonder if we could gain access to this capability in chrome documents, so that about:logins and the backup management UI I'm working on can take advantage of this.

emilio, can you think of any reason why we wouldn't want to do that?

Comment 3

[Mike Conley (:mconley) (:⚙️)]

(Note that we'd probably need some way to override this on a case-by-case basis, or to opt in on a case-by-case basis, since at least about:logins has their own reveal button that we'd be doubling up on if we turned this on right now).

Comment 4

[Hanna Jones [:hjones]]

FWIW even when bug 1743046 is finished we'll probably still end up creating a reusable component for styling input/form elements, including password inputs. There are a couple reasons for this:

• We'll want to encapsulate the expected input styles for our chrome/in-content surfaces in a custom web component
• We'll want to ensure consistent markup as well as usability and accessibility for the combo of input + label (when this has to be re-implemented every time results vary)

Landing bug 1743046 will change the details of how we implement a password input component, but I don't think it'll impact whether or not we build the component.

Comment 5

[Emilio Cobos Álvarez (:emilio)]

(In reply to Mike Conley (:mconley) (:⚙️) from comment #2)

While we wait for bug 1743046 to be addressed, I wonder if we could gain access to this capability in chrome documents, so that about:logins and the backup management UI I'm working on can take advantage of this.

You mean like https://phabricator.services.mozilla.com/D173476? That was waiting on Micah to use that in about:logins so that we don't show the two buttons...

Comment 6

[Mike Conley (:mconley) (:⚙️)]

Wow, holy smokes, looks like Micah's done most of the work there for me! Looks like it's stalled out. Let me see what's going on over there.

Comment 7

[Mike Conley (:mconley) (:⚙️)]

I spoke with Micah - apparently, this kinda stalled out because of the additional effort required to get about:logins to integrate with the capability.

Considering where my team wants this capability (about:preferences, and maybe about:welcome down the road), I think we can probably get away with just not including about:logins for now in the about: pages that could get this feature.

hjones: would there be any objections from the ReComp team with going ahead and making the reveal button visible on some (but not all) password fields in chrome privileged documents?

Comment 8

[Hanna Jones [:hjones]]

Thanks for the additional context!

(In reply to Mike Conley (:mconley) (:⚙️) from comment #7)

Considering where my team wants this capability (about:preferences, and maybe about:welcome down the road), I think we can probably get away with just not including about:logins for now in the about: pages that could get this feature.

hjones: would there be any objections from the ReComp team with going ahead and making the reveal button visible on some (but not all) password fields in chrome privileged documents?

I think we might have a slight objection to (or maybe just a preference to avoid) any change that would lead to divergent input implementations and possibly make things harder to reconcile/standardize down the line. I feel like enabling a built-in show password functionality on all about pages except about:logins could lead to us creating a second version of a password input component - since we'll still want the styling and accessibility/usability characteristics to be identical on all the pages about: pages you listed, plus encapsulate things like error messages, hints, etc. We want to discourage duplicate implementations of the same UI patterns whenever possible.

I'm curious if it would be possible to pursue both paths - hoist up the about:logins code to create an input component that's globally available while also enabling the built-in hide/show functionality. The component could be configurable and/or emit events to be handled by consumers in such a way that we could use the built in hide/show where available.

In any case though our team is happy to help and definitely won't block y'all from pursuing whatever path leads to getting things done on the timeline you need!

Comment 9

[Emilio Cobos Álvarez (:emilio)]

Would an opt-out of the "reveal-password" behavior (like appearance: textfield for example which removes the spinners of <input type=button>) help? Seems that'd allow enabling the native reveal button, while allowing about:logins from undoing that.

And IMHO if we ever want to ship that to the web, we're going to need it anyways, so...

Comment 10

[Mike Conley (:mconley) (:⚙️)]

Perhaps. I'm in talks with the Reusable Components team about how to go about planning for a kind of shared component that about:logins could use that likely wraps the <input type="password"> field with the DOM mask/unmask button. Stay tuned for that.