Bitwarden is overzealous to fill various search fields, breaking functionality of many sites

[michaldybczak]

Steps To Reproduce

1. Go into site with various search fields (for filters or finding a content of the site), for example: https://eztvx.to/home
2. Even when there is no login data, the search field shows BW icon and options, breaking the usual browser's autofill of those fields. This is even more problematic on sites that are used for work, like managing various site engines.

Expected Result

Not-logging fields should be free of BW overlay.

Actual Result

On placing a cursor in a search field, BW icon shows up, offering BW options, which breaks usual browser's functions for selection.

Screenshots or Videos

Additional Context

Since a week I spotted an issue when I work with various sites, like site management backends, but also on normal public sites which have search fields. Now, Bitwarden detects them and adds those icons to fill it, which breaks the usual functionality of those fields like filling them with the text based on previous entries.

My workflow was, that I simply typed the first letters of previous text, then list of previous entries showed up (on Firefox), then I simply used arrows and enter keys to choose the proper one, then enter to confirm the selection. This is broken now and even if there is no BW data to be filled on a specific site, BW adds its icon and breaks the keys action by overtaking them, when I don't need it.

This was probably submitted by others here, but I'm just a regular user and lack of technical expertise to find a proper, more technically focused topic that is discussing just that.

Since CMS sites require logins, I can't give them as an example, but see a popular torrent site like:

https://eztvx.to/home

where search field is overtaken by BW. This becomes a serious issue.

I tried to set the logging option to be run only in the specific subsite/url (instead autochoose), but that doesn't help, and it is not dependent on the existing BW data. It still shows BW icon in the search field, then info that there is no login data and a link to create a new identity.

This is too aggressive behavior, breaking the functionality of many sites. This also interferes with my work, so it's becoming a huge problem to the point, that I consider looking for alternative password managers. I love BW but this is breaking it too seriously :(.

Operating System

Linux

Operating System Version

Operating System: Manjaro Linux KDE Plasma Version: 6.1.4 KDE Frameworks Version: 6.5.0 Qt Version: 6.7.2 Kernel Version: 6.10.6-10-MANJARO (64-bit) Graphics Platform: Wayland Processors: 16 × AMD Ryzen 7 7840HS w/ Radeon 780M Graphics Memory: 30.6 GiB of RAM Graphics Processor: AMD Radeon 780M Manufacturer: TUXEDO Product Name: TUXEDO Sirius 16 Gen1

Web Browser

Firefox

Browser Version

130.0

Build Version

2024.8.1

Issue Tracking Info

• [X] I understand that work is tracked outside of Github. A PR will be linked to this issue should one be opened to address it, but Bitwarden doesn't use fields like "assigned", "milestone", or "project" to track progress.

[BBGhub]

Hi there!

Thank you for your report, it seems like it is a duplicate of this one https://github.com/bitwarden/clients/issues/10814 and https://github.com/bitwarden/clients/issues/10815

If you wish to add any further information/screenshots/recordings etc., please feel free to do so at any time in there - our engineering team will be happy to review these. You may also find a workaround for your specific browser within the GitHub issues comments above.

This issue will now be closed.

Thanks!

[LightningRocks]

@BBGhub I'm sorry if this comes off as rude, but I don't think you read this correctly at all based on what this request was talking about. It seems more like a duplicate #10753 and there are definitely bugs in relation to that issue even though it's been already closed. I can confirm that on a variety on sites it's still breaking stuff with the Bitwarden autofill even with the newest 2024.9.0 version of the client for me on OS Mac + Windows, Web Browsers of Brave + Edge. If you need any more data from me, I'd be happy to oblige

[f-o]

Today was the day I finally went to Github to look if this had been addressed by others, after having lived with this bug for quite some time now.

I too experience Bitwarden think that many input-boxes are credential fields, when they are in fact not.

The issue started some time ago. More than a month. Of course I do not remember when exactly, but I am fairly certain that something was updated in the add-on, which initiated this bug, as it suddenly started showing on a site I frequent daily.

It's very unfortunate to have this bug, and especially to see that the previous issue (https://github.com/bitwarden/clients/issues/10753) was closed without a proper fix. This is more than a minor annoyance, at this point, as the overlay is set to have the highest z-index, and will block user interactions with dropdowns, as can be seen in the example below.

https://github.com/user-attachments/assets/5c96f5ca-af60-43f9-ac5e-af99eea1b7b9

Every single input-box, on this checkout page, is being falsely validated as credentials input by Bitwarden.

<form action="" method="POST" novalidate="" id="Form1" class="km09ry0 _1fragem2n">
    <input id="TextField0" name="firstName" placeholder="Fornavn" required="" type="text" aria-required="true"
        aria-labelledby="TextField0-label" autocomplete="shipping given-name"
        class="_7ozb2uq _7ozb2up _1fragempf _1fragemx8 _1fragemsd _1fragemwf _7ozb2ur _7ozb2u11 _7ozb2u1h">

    <input id="TextField1" name="lastName" placeholder="Efternavn" required="" type="text" aria-required="true"
        aria-labelledby="TextField1-label" autocomplete="shipping family-name"
        class="_7ozb2uq _7ozb2up _1fragempf _1fragemx8 _1fragemsd _1fragemwf _7ozb2ur _7ozb2u11 _7ozb2u1h">

    <input id="TextField2" name="address2" placeholder="Lejlighed, etage osv. (valgfri)" type="text"
        aria-required="false" aria-labelledby="TextField2-label" autocomplete="shipping address-line2"
        class="_7ozb2uq _7ozb2up _1fragempf _1fragemx8 _1fragemsd _1fragemwf _7ozb2ur _7ozb2u11 _7ozb2u1h">

    <input id="TextField3" name="postalCode" placeholder="" required="" type="text" inputmode="numeric"
        aria-required="true" aria-labelledby="TextField3-label" autocomplete="shipping postal-code"
        autocapitalize="characters"
        class="_7ozb2uq _7ozb2up _1fragempf _1fragemx8 _1fragemsd _1fragemwf _7ozb2ur _7ozb2uv _7ozb2uu _1fragemwu _1fragemwp _1fragemx4 _7ozb2u11 _7ozb2u1h">

    <input id="shipping-address1" name="address1" placeholder="" required="" type="text" aria-autocomplete="list"
        aria-controls="shipping-address1-options" aria-owns="shipping-address1-options" aria-expanded="true"
        aria-required="true" aria-labelledby="shipping-address1-label" aria-haspopup="listbox" role="combobox"
        autocomplete="none" autocorrect="off"
        class="_7ozb2uq _7ozb2up _1fragempf _1fragemx8 _1fragemsd _1fragemwf _7ozb2ur _7ozb2uv _7ozb2uu _1fragemwu _1fragemwp _1fragemx4 _7ozb2ut _7ozb2us _1fragemsx _1fragemt7 _7ozb2u11 _7ozb2u1h"
        aria-activedescendant="shipping-address1-option-0">
</form>

Hopefully this can get some more exposure by the developers, as it feels unfortunate to have an introduced bug severely limit the user experience. I think having the earlier and original issue be reopened, so we can contain relevant information in a single place, would be the best order of action at this point.

[jsspen]

Same issue here. Between this and #10814 / #10815 Bitwarden is driving me up a wall lately.

[cagonzalezcs]

@michaldybczak

Thank you for the bug report, we have some code changes coming in the v2024.9.1 release later this week that should help to alleviate the "overzealous-ness" of the inline menu.

Beyond that, I also spoke with the team about incorporating some settings to the inline menu's behavior that allows users to disable the inline menu for card and identity ciphers if desired. Those will be implemented and released in a future version of the extension (past the v2024.9.1 release).

The reason we're looking to incorporate that kind of setting is due to concerns brought up relating to the inline menu where users are expecting the menu to only appear for login forms. An example of that concern comes with your comment @f-o , looking at your markup it seems that the inline menu is correctly placing itself on the field to allow for filling Identity ciphers. The form fields have an autocomplete value that indicates that they should be filled by identity ciphers, and as a result it is "correct" for the inline menu to appear there, even if it isn't desired by you.

I'll keep this thread open for now and encourage discussion on the issue. In effect, we're discussing the UX of this feature, not just a bugfix; something which I find valuable as we refine the feature's implementation.

[michaldybczak]

Thanks @cagonzalezcs.

If this is really the case, then the blame falls on the site developers who put such autocomplete value into those fields. Maybe they have some reasons, or maybe not, and this is just a sloppy coding on their part. Either way, this is something that Bitwarden cannot control and which causes issues for users. On one hand, users expect Bitwarden to fill automatically, on the other hand, it can take over the forms which are not meant for login data. I guess, there is no good solution for everyone here, and if you choose some middle ground, none will be happy... But maybe there are some side solutions, like option to disable autofilling in certain sub-pages or sub-domains (exception list)? Or disabling auto-fill for a specific domain, and then I could decide, what is worse: having to click to fill login, but have no intrusions elsewhere in the site, or accept issues if autofill for login is more important. Currently, we can do nothing and it just breaks functionality of some sites. Eztv as one example that is not especially significant here. My main problem is with the service to manage certain site I work with and that breaks my workflow and forces me to pick up the mouse, which takes more time and is inconvenient. On other hand, I love autofill feature and I relay on it in other sides ;).

First, let's see how the update works. Do you have an estimate time of this update?

[cagonzalezcs]

@michaldybczak

Just got word from our release team that v2024.9.1 has been submitted to the Chrome, Edge, Firefox, and Opera stores (Apple's store is pending due to some issues caught in regression). You should be seeing the changes soon.

[LightningRocks]

Today's 9.1 update seems to fix my issue. Thanks again to the staff for getting this solved!

[michaldybczak]

I see 2024.9.1 as server version, but browser version is still 2024.9.0. I already restarted the browser. Is there any way to force the update manually? Or maybe the browser version and server version are published at slightly different times and I just need to wait a little bit longer?

[cagonzalezcs]

@michaldybczak

While the extension has been submitted to the aforementioned stores, you might not see the v2024.9.1 version available yet due to the submission review process that each store provides. Edge has a near instantaneous approval of a submitted extension update, but Chrome, Firefox, and Safari take some time (with Firefox and Safari taking up to a week to approve submissions).

[michaldybczak]

Sorry to keep you waiting. The update fixed the issue, so I'm closing it. Thank you!