In Italian, autofill translates to “riempimento automatico”, but the button we use is labelled “Riempi”, barely longer than the English version. Both the French and German translations you provided can also be shortened to Füllen and Saisie, which are also about the same length, and the reason the longer version is used is because the translators haven’t translated that string yet. Nothing that can’t be fixed or won’t fix itself with time.
I do still believe a label is much better than an icon, because it’s not only MUCH clearer to understand (and doesn’t require a tutorial), but the button is also much bigger and therefore easier to click, which is important given the button is by far the main function of the entire extension.
To me, it doesn’t make sense that the button size should depend on language. Not every language has short word options for every button label. And I already agreed that the autofill button could be larger than the other two buttons, but I think that the button width should be the same for all languages.
Even in English, if the “Collection” button and the other filter buttons weren’t so wide, it wouldn’t be necessary for them to take up two rows. These have an icon and a text label — would be nice to allow the user to disable the text.
But we evidently disagree, which is fine. As long as this gets fixed in the compact mode.
Glad to see some the initial implementation of some improvements in the updated version 2024.11.999! However, compared to the “Key Updates” described in the top post of this thread, all promised changes have not yet been implemented:
The Search field autofocus is not working in version 2024.11.999. One still needs a mouse click or four presses of the Tab to focus the Search field.
This does not appear to be available in version 2024.11.999.
Also not available in version 2024.11.999.
In version 2024.11.999, the Notes height is still limited to 2 lines of text (approximately 32 characters per line).
The two bugs mentioned by @Waith2044 have been fixed, but a new bug has been introduced: there is now no longer any limit to how small of a number can be specified for the length (e.g., it is possible to specify a value smaller than 5 for a password — even 0 or a negative number like -999999999999999999 — although the actual password length is limited at 5 characters).
Furthermore, the passphrase length has a minimum length of 6 words, which is too high; this would be equivalent (in entropy) to a 12-character password — so if the minimum password length is 5, then the minimum passphrase length should not be greater than 3 words (equivalent in strength to a 6-character password). Having inconsistent length limits for passwords and passphrases (i.e., not equivalent in terms of entropy) signals to advanced users that Bitwarden developers do not actually have a good understanding of password strength/entropy (which would be worrisome if true!).
Personally, I don’t think there should be any length limits, or if limits are enforced, then they should be low. There are legitimate use-cases for wanting to generate, say, a 4-digit PIN. Thus, if length limits are not going away, the minimum password length shouldn’t be greater than 4 characters, which means that the minimum passphrase length (equivalent in entropy to a 4-character password) should be 2 words.
In addition, there are a few other loose ends that related to statements made by @dflinn in the previous thread:
Persistent UI: This is only partially working. Unfortunately, this does not work for the most important use-case: when creating or editing a vault item, all work (new or modified information) is lost if the browser extension is closed and re-opened. Furthermore, the view shown in the browser extension is only remembered if one does not switch the active tab in the browser; it does not persist if one switches to a different browser tab before reopening the extension (this always opens to the default “Vault” view). Moreover, even if staying on the same browser tab, the UI does not remember the state of the Vault/Collection/Folder/Type filters, nor does it retain the scrollbar position, field focus, or any search terms that may have been entered into the search bar.
I think that likely users of the compact mode will not need any explanation for why no matching logins exist. At the very least, make this text significantly shorter in compact mode (e.g., “No matching logins” would suffice).
One of these is not like the other. When editing custom fields, why is the formatting of the name of a boolean custom field not consistent with the field name of other custom field types (small font, gray), but instead uses the formatting that is associated with the field value of text, linked, and hidden fields (extra-large white font)?
An oddity. When viewing a login item, why is the list of URIs labeled “Autofill Options”? There is no autofill functionality available for any item in the list, so the label wording for this section is inexplicable. In addition, if you instead label that section “Websites”, then you would be able to omit the redundant “Website” label displayed above every URI (unnecessarily doubling the height of each URI item).
totally agree that the minimum passphrase length of 6 words is excessive and should be within the user control, not dictated by the application. Forcing a minimum of 6 words then requiring the user to delete extraneous words to comply with password length requirements of some applications/sites is a backwards step.
Hey @grb,
Just wanted to let you know that while we aren’t responding to everything, we are reading everything in these forums on a daily basis. Appreciate all the feedback.
Some of the improvements I highlighted at the top of this thread are still in development, so not everything has made it in yet.
Another thing I just saw (beta extension version 2024.11.999): If you add a vault item and use the password generator there, your choice (password / passphrase) is displayed a bit odd now:
If I choose “password” the word passwordis not visible:
Of course, that is a “Crowdin thing”. But it is maybe two weeks ago, that I was in Crowdin the last time - and didn’t see any translation for that left / open.
FYI, I am not able to reproduce this issue (Bitwarden extension 2024.11.999, Chrome 131.0.6778.71, Windows 11 23H2 22631.4460), either in Light mode or Dark mode, in an English-language UI. Maybe try disabling/enabling or uninstalling/reinstalling the extension?
@Kevin_Harris I would like to offer a suggestion for how to improve navigation in the new UI. It seems that the UI structure has four top-level pages (i.e., the “Vault”, “Generator”, “Send”, and “Settings” tabs), in which it is possible to switch tabs using the navigation bar at the bottom, and also to switch accounts or lock/log out (using the profile avatar displayed in the upper right corner). However, if one opens any lower-level page, then access to the bottom navigation bar and the profile avatar is lost.
As a result, I’ve often found myself frustrated by the inability to quickly access these UI elements, and to quickly return to the Vault view. This is especially problematic when one has drilled down into a low-level page such as Settings > Notifications > Excluded Domains or Search > View > Edit > Attachments, so that several repeated clicks of the “Back” (<) button are required to return to the main Vault page. The problem is exacerbated by the new “persistent UI” functionality, because closing and re-opening the extension no longer returns to the Vault page as a default.
My suggestion would be to add a “Home” button to all lower-level pages (i.e., every page except the top-level “Vault”, “Generator”, “Send”, and “Settings” pages), which would return the user the Vault page. On the lower-level pages, there is currently only a single icon (the pop-out button) in the upper right corner, so this would be a good place to add a “Home” button, as shown in the mock-up below:
Feature Request: Home Button
Hi everyone " i’m new here and i come from 1P" one thing i like about 1Password its that you can Customize, “Your’e STUFF”
So I would like to suggest re-TAP-And rename it a home, where you can customize things like important things or add other items etc.. It would be great if we could customize some things!
What do you think guys?
Please allow an option to include more than one number when generating a username from a random word. It would be nice to include anywhere from 1–6 numbers in the username. For example, I created the username for this forum using the old Bitwarden extension, which allowed four numbers at the end.
Bug Report: Passkey Handling with Locked Extension
If a Relying Party (on a non-excluded domain) request passkey authentication while the extension is locked, then the extension is expected to prompt the user to unlock the vault, with an option to “Use your device or hardware key” for handling the passkey authentication instead of using Bitwarden. If the user unlocks their vault when prompted, they should be presented with the matching passkeys available in the Bitwarden vault, and be allowed to select one for the authentication ceremony. This is the way that in works in the production version of the browser extension, but this workflow is completely broken in the beta extension (version 2024.11.999).
When the Relying Party requests passkey authentication while the beta browser extension is locked, the following pop-out window appears:
Note that the bottom of the UI is cut off in the pop-out window (pushed below the fold by the vast expanses of empty space in the UI), but even if one uses the scroll bar (or resizes the pop-out window) to reveal the full contents of the UI, there is no option to Use your device or hardware key.
If the user proceeds to unlock the vault, then the pop-out just opens to a static “Vault” page. There is no option to use any stored passkeys, and the floating pop-out window does not automatically close after unlocking has been completed.
The beta version is now in production (version 2024.12.0), so I am closing this thread. Additional comments should be posted in the community forum feedback thread linked below:
Using 5 different font sizes creates an overall appearance that is chaotic, and difficult to parse.
One of these is not like the other. When editing custom fields, why is the formatting of the name of a boolean custom field not consistent with the field name of other custom field types (small font, gray), but instead uses the formatting that is associated with the field value of text, linked, and hidden fields (extra-large white font)?
An oddity. When viewing a login item, why is the list of URIs labeled “Autofill Options”? There is no autofill functionality available for any item in the list, so the label wording for this section is inexplicable. In addition, if you instead label that section “Websites”, then you would be able to omit the redundant “Website” label displayed above every URI (unnecessarily 
