Hide recovery key when prompting for verification #30471
Merged
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
4 tasks
Member
Author
|
Related: #30174 |
andybalaam
force-pushed
the
andybalaam/hide-recovery-key
branch
from
d1814e0 to
57238ee
Compare
andybalaam
force-pushed
the
andybalaam/hide-recovery-key
branch
2 times, most recently
from
089d7c5 to
c4f4705
Compare
andybalaam
force-pushed
the
andybalaam/hide-recovery-key
branch
2 times, most recently
from
5cf85eb to
ceaae38
Compare
dbkr
approved these changes
Aug 4, 2025
t3chguy
reviewed
Aug 4, 2025
t3chguy
reviewed
Aug 4, 2025
uhoreg
approved these changes
Aug 4, 2025
Member
uhoreg
left a comment
uhoreg
left a comment
There was a problem hiding this comment.
Looks OK code-wise from a crypto standpoint. In the screenshots, it looks like the border around the input is missing sometimes, but I assume that's either a bad screenshot, or my computer is displaying it weirdly. (The screenshots look a bit blurry in general.)
Member
Author
Thanks, fixed in c6400ca |
… in designs See https://www.figma.com/design/ZodBLtGnKmRTGJo5SGLnH3/ER-137--Excluding-Insecure-Devices?node-id=92-8818&t=02JILBe2n7sx7ljU-1 In parallel with this, I have updated security_key_title in localazy.
andybalaam
force-pushed
the
andybalaam/hide-recovery-key
branch
from
c6400ca to
0e192d9
Compare
Dileep9999
pushed a commit
to hemanth-nag/element-web
that referenced
this pull request
Oct 8, 2025
* Separate security_key_title from security_key_label since they differ in designs See https://www.figma.com/design/ZodBLtGnKmRTGJo5SGLnH3/ER-137--Excluding-Insecure-Devices?node-id=92-8818&t=02JILBe2n7sx7ljU-1 In parallel with this, I have updated security_key_title in localazy. * Hide recovery key on entry screen after login
snowping
pushed a commit
to Novaloop-AG/element-web
that referenced
this pull request
Dec 30, 2025
* Separate security_key_title from security_key_label since they differ in designs See https://www.figma.com/design/ZodBLtGnKmRTGJo5SGLnH3/ER-137--Excluding-Insecure-Devices?node-id=92-8818&t=02JILBe2n7sx7ljU-1 In parallel with this, I have updated security_key_title in localazy. * Hide recovery key on entry screen after login
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Improve one of the cases for Web described in element-hq/element-meta#2888
When prompting the user for a recovery key in order to verify (either on login or later), hide the key by default and allow the user to show it:
We do this by using the Compound
PasswordInputcomponent.The designs for this are here: https://www.figma.com/design/ZodBLtGnKmRTGJo5SGLnH3/ER-137--Excluding-Insecure-Devices?node-id=102-43729&t=QmewENUd7f6Tmw9U-1
This PR does not bring us fully into line with the designs, but I think it is a step forward:
I think fixing the remaining problems would require creating a new Compound component, which is probably out of my scope for this task.
(With thanks to @meramsey for working on this under #30393 , which this PR supersedes.)