Closed ChronSyn closed 6 months ago
Hi @ChronSyn ,
Thank you for reaching out regarding this!
We use GitHub issues as a place to track bugs and other development related issues. The Bitwarden Community Forums has a Feature Requests section for submitting, voting for, and discussing requests like this one: https://community.bitwarden.com/c/feature-requests/
Please sign up on our forums and search to see if this request already exists (https://community.bitwarden.com/signup). If so, you can vote for it and contribute to any discussions about it. If not, you can re-create the request there so that it can be properly tracked.
This issue will now be closed. Note that the “Closed as not planned” status is for internal tracking purposes only, please do not hesitate to send us your suggestions to the forum.
Thank you!
Could you offer some advice on where the content for this window can be found in the source code?
I'm willing to consider working on a PR to resolve the issue but it's not possible to even identify where the window is located from the browser dev tools due to it closing the moment that a user taps anything else.
(I'd agree about it being a feature suggestion if I was just looking for customisation, but being unable to identify which entry a user should choose because of styling is a bug)
@ChronSyn
So before I describe the process for how your request could be implemented, I'd like to suggest that you can always hover over these "cutoff" name elements to view the full content. The title
attribute is set on both the vault item name and the login, so they should present their content fully when hovering over the element.
Now that said, the process for determining the width of the inline list goes through this workflow
On focus of the input, we determine the dimensions of the most recently focused input field within the AutofillOverlayContentService. This is done by making a call to getBoundingClientRects
on the element, and passing those values in a updateFocusedFieldData
message sent to the extension background.
--> When updating the position of the inline menu, we reference the most recently focused field data to determine its dimensions within the OverlayBackground and pass a updateIframePosition
message to the inline menu list through an extension messaging port.
--> The port then reacts to the message within the AutofillOverlayIframeService and updates the dimensions of the inline menu iframe.
To have something like you are requesting would require determining dimensions of the inline menu iframe from within the frame itself, which is possible to do. That would require some logic to determine these required dimensions within the AutofillOverlayList extension page script and then posting a message to the AutofillOverlayIframeService to affect the dimensions of the iframe.
Steps To Reproduce
Expected Result
The autosuggest box should be wide enough to clearly see the full title
Actual Result
The autosuggest box is too narrow to view longer titles, making it very difficult for users to identify which site a login is for in some scenarios.
Screenshots or Videos
Additional Context
Note that the details in the screenshot have been partly censored, but hopefully evidence that it's impossible to identify which credentials of the top 2 would apply, as both are for different sites hosted on the same domain.
Even if I opt to change the URI detection method, this same problem would also cause problems if I had multiple logins for a site (I'm a developer and often have multiple accounts with different roles, permissions, or other account-specific criteria for client products I work on).
Ideally, make the width of the pop up at least as wide as the widest item (e.g. average character width * number of characters), or allow users to customise it.
Operating System
Windows
Operating System Version
No response
Web Browser
Brave
Browser Version
No response
Build Version
2024.2.1
Issue Tracking Info