When I make the password visible, with most of my auto-generated passwords that use passphrases, they easily go off the screen, and when I make a password visible, I am no longer trying to go the route of copy-paste or autofill, I am now down a path of wanting to see the password (personally, for cases where I can’t copy paste as the “password” is going into another device or similar that can’t have BW. So the old functionality of being able to see the whole password without needing to scroll or similar where I can only see partial at a time (and the scroll functionality is difficult, I have found that keyboard arrows are the best typically, but that isn’t the fundamental issue), is problematic from a UX standpoint.
Additionally, this does not match behavior on other platforms, ios, etc where when the view is toggled, the screen expands to show entire password.
ios:
extension:
TLDR;
Problem: Can’t view entire password when toggling visibility
Proposed solution: Only when visibility is toggled, make the password field large enough to encompass the whole password so it is visible, matching behavior on other platforms like mobile.
If this would be better as a GH issue or similar, just lmk, this is my first time posting something so hopefully this is the right place
This seems like a really good idea, and not just for the password field. Unlike the iOS example, I probably would experiment with also making the field full width and moving the buttons to a new line to minimize the amount of wrap.
I like that suggestion; that would save a lot of the limited horizontal width that exists on ios as well! Vertical space is limited on mobile of course, but not as much as horizontal.
I’d imagine that the buttons would just be the first thing to wrap when you make it visible on ios. Aka, it looks as is when not visible, and when you click visible button, the first things to wrap are those buttons. Only downside with that specific implementation, is now a button may move out from under where your finder is.
… I’m just thinking of a better “name” for the future request. Shouldn’t a feature request express or make clear what you want the extension to be able to do (which feature you require) - and not what the extension can’t do?
How about something like “Make entire password readable, when visibility is toggled”? (though I lack the finer points of the language as German potato, so if you find something better… either way, we can change it for you)
@Unmanaged312 I modified your topic title to be more descriptive of the proposed feature. (title was: “Can’t view entire password anymore in extension”; changed to: “Restore ability to see full password when visibility is toggled”).
Technically, you could also report this as a bug (“New Issue”) on GitHub, since the required functionality was present in version 2024.11.2, but was lost in version 2024.12.0.
Would it be worth separating out this suggestion for ios (or other client) specific changes into it’s own topic since that would be more of a feature request directly for changes to the button locations vs bug fix? Or not worth it as it likely won’t change or isn’t significant enough?
Saw your bug report on GitHub. To reduce the chances that the issue is deemed to be a feature request and closed, I would suggest revising the GitHub thread title to sound less like a feature request, and more like a bug report. For example:
“Display of passwords is truncated in new browser extension UI”
or
“Toggling password visibility fails to display full password”
