github-starred/android
2
0
Fork 0
mirror of https://github.com/bitwarden/android.git synced 2026-03-12 05:04:17 -05:00
Code Issues 144 Packages Projects Releases 116 Wiki Activity

[Android] Match Detection settings misbehaving with Inline Autofill #1459

New Issue
Closed
opened 2025-11-26 22:49:41 -06:00 by GiteaMirror · 10 comments
GiteaMirror commented 2025-11-26 22:49:41 -06:00
Owner
Copy Link

Originally created by @rg9400 on GitHub (Jun 9, 2022).

Steps To Reproduce

  1. Create two password items. First is for domain.com/test or any subpath. This needs to be set to use Match Detection as "Starts With". Then create one for domain.com (has to match prior domain). Set this url to use Match Detection "Exact"
  2. Enable Inline Autofill and Accessibility services for the quick-action tile
  3. Go to domain.com/test
  4. Try to use the inline autofill. Notice how it pulls the password item for domain.com and not the one for domain.com/test
  5. Try to use the quick setting tile. Notice how it pulls the password item for domain.com/test and not domain.com

Expected Result

The Inline Autofill should behave like the Quick Actions tile in the above example. In other words, it should respect that the domain.com password is not relevant since domain.com/test is not an exact match for domain.com, and likewise, it should see that domain.com/test is meeting the match detection for domain.com

Actual Result

I am not sure exactly what is happening because in both password items, the match detection option is failing. Yet it is still recognizing that domain.com is the base domain for domain.com/test and giving that password. It seems to work in most other cases and is only failing in this type of specific example, at least that I have noticed. Might be some sort of edge case?

Screenshots or Videos

No response

Additional Context

No response

Operating System

Android

Operating System Version

Android 12

Device

Samsung S22 Ultra

Build Version

2022.05.0 (4636)

Beta

  • Using a pre-release version of the application.
Originally created by @rg9400 on GitHub (Jun 9, 2022). ### Steps To Reproduce 1. Create two password items. First is for `domain.com/test` or any subpath. This needs to be set to use Match Detection as "Starts With". Then create one for `domain.com` (has to match prior domain). Set this url to use Match Detection "Exact" 2. Enable Inline Autofill and Accessibility services for the quick-action tile 3. Go to `domain.com/test` 4. Try to use the inline autofill. Notice how it pulls the password item for `domain.com` and not the one for `domain.com/test` 5. Try to use the quick setting tile. Notice how it pulls the password item for `domain.com/test` and not `domain.com` ### Expected Result The Inline Autofill should behave like the Quick Actions tile in the above example. In other words, it should respect that the `domain.com` password is not relevant since `domain.com/test` is not an exact match for `domain.com`, and likewise, it should see that `domain.com/test` is meeting the match detection for `domain.com` ### Actual Result I am not sure exactly what is happening because in both password items, the match detection option is failing. Yet it is still recognizing that `domain.com` is the base domain for `domain.com/test` and giving that password. It seems to work in most other cases and is only failing in this type of specific example, at least that I have noticed. Might be some sort of edge case? ### Screenshots or Videos _No response_ ### Additional Context _No response_ ### Operating System Android ### Operating System Version Android 12 ### Device Samsung S22 Ultra ### Build Version 2022.05.0 (4636) ### Beta - [X] Using a pre-release version of the application.
GiteaMirror added the good first issuebug labels 2025-11-26 22:49:41 -06:00
GiteaMirror commented 2025-11-26 22:49:42 -06:00
Author
Owner
Copy Link

@rg9400 commented on GitHub (Sep 9, 2022):

@creyhani I noticed this issue was marked closed, but I am still having this bug. Is it released to a beta/stable build yet?

@rg9400 commented on GitHub (Sep 9, 2022): @creyhani I noticed this issue was marked closed, but I am still having this bug. Is it released to a beta/stable build yet?
GiteaMirror commented 2025-11-26 22:49:42 -06:00
Author
Owner
Copy Link

@clayadams5226 commented on GitHub (Sep 13, 2022):

Hey @rg9400, apologies for this getting closed without a comment that was an oversight on our part. Have you had a chance to test this on the most recent Android build? We are unable to reproduce it on our side.

@clayadams5226 commented on GitHub (Sep 13, 2022): Hey @rg9400, apologies for this getting closed without a comment that was an oversight on our part. Have you had a chance to test this on the most recent Android build? We are unable to reproduce it on our side.
GiteaMirror commented 2025-11-26 22:49:43 -06:00
Author
Owner
Copy Link

@rg9400 commented on GitHub (Sep 14, 2022):

Yes, I am still having this issue on the latest build. I am going to show my exact setup. I have this URL Match Detection configured for my "Plex" item. Everything blocked out is my domain. You can see that I have the root domain as an exact match, and a variety of subfolders as Stars With match

image

This is my "Filebrowser" item. It is set to a different subfolder, with URL Detection set to Starts With as well

image

The theory is that if I go to domain.com, domain.com/tautulli, domain.com/#Stuff, then Plex item should pop up. This works as expected.

However, if I go to domain.com/filebrowser, then I expect to see the Filebrowser item pop up. This is not happening with Inline Autofill. Crucially, this works fine on Desktop and even using the Settings Tile or Autofill Overlay. Only Inline Autofill is failing and shows the Plex item. I am unable to take a screenshot of the overlay/Settings Tile, but trust me it shows the Filebrowser item correctly. So only the Inline Autofill is failing with something related to this configuration.

190051736-85689f18-e995-4d87-9964-c5e328209f52

image

@rg9400 commented on GitHub (Sep 14, 2022): Yes, I am still having this issue on the latest build. I am going to show my exact setup. I have this URL Match Detection configured for my "Plex" item. Everything blocked out is my domain. You can see that I have the root domain as an exact match, and a variety of subfolders as Stars With match ![image](https://user-images.githubusercontent.com/39887349/190049653-264fc02f-67ce-4cde-a694-312bea2feaa7.png) This is my "Filebrowser" item. It is set to a different subfolder, with URL Detection set to Starts With as well ![image](https://user-images.githubusercontent.com/39887349/190049810-f6421c06-d688-449c-b41a-c5943649e499.png) The theory is that if I go to domain.com, domain.com/tautulli, domain.com/#Stuff, then Plex item should pop up. This works as expected. However, if I go to domain.com/filebrowser, then I expect to see the Filebrowser item pop up. This is not happening with Inline Autofill. Crucially, this works fine on Desktop and even using the Settings Tile or Autofill Overlay. Only Inline Autofill is failing and shows the Plex item. I am unable to take a screenshot of the overlay/Settings Tile, but trust me it shows the Filebrowser item correctly. So only the Inline Autofill is failing with something related to this configuration. ![190051736-85689f18-e995-4d87-9964-c5e328209f52](https://user-images.githubusercontent.com/39887349/190052657-fc6bf54f-247c-4041-9c5e-9291dccf84d1.png) ![image](https://user-images.githubusercontent.com/39887349/190052422-bb8ceae0-7bac-4b98-82eb-d5d87ae0713e.png)
GiteaMirror commented 2025-11-26 22:49:43 -06:00
Author
Owner
Copy Link

@clayadams5226 commented on GitHub (Sep 14, 2022):

Thanks for the added details @rg9400. We'll get a couple more people to take a look at this.

@clayadams5226 commented on GitHub (Sep 14, 2022): Thanks for the added details @rg9400. We'll get a couple more people to take a look at this.
GiteaMirror commented 2025-11-26 22:49:43 -06:00
Author
Owner
Copy Link

@SgtBatten commented on GitHub (Oct 29, 2022):

I am also experiencing this same issue.

I run my own nginx webserver using swag and have many domains like @rg9400

the password for https://mydomain.net has 3 URIs all set to exact

https://domain.net
https://domain.net/#Homepage
https://domain.net/#OrganizrLogin

I run many reverse proxied services all with similar setups e.g Tautulli

https://tautulli.domain.net is the URI that is reverse proxied. I have this set to exact or starts which both work fine
When I access through Organizr it presents each app as an iframe at e.g https://domain.net/#Tautulli
I set this to exact or starts with and both work as expected on my pc browser extention, but on mobile (pixel 4a and pixel 7 pro) I am given options for domain.net and not tautulli. If i swipe down and select autofill from the android settings tiles it only suggests the correct tautulli login.

@SgtBatten commented on GitHub (Oct 29, 2022): I am also experiencing this same issue. I run my own nginx webserver using swag and have many domains like @rg9400 the password for https://mydomain.net has 3 URIs all set to exact https://domain.net https://domain.net/#Homepage https://domain.net/#OrganizrLogin I run many reverse proxied services all with similar setups e.g Tautulli https://tautulli.domain.net is the URI that is reverse proxied. I have this set to exact or starts which both work fine When I access through Organizr it presents each app as an iframe at e.g https://domain.net/#Tautulli I set this to exact or starts with and both work as expected on my pc browser extention, but on mobile (pixel 4a and pixel 7 pro) I am given options for domain.net and not tautulli. If i swipe down and select autofill from the android settings tiles it only suggests the correct tautulli login.
GiteaMirror commented 2025-11-26 22:49:43 -06:00
Author
Owner
Copy Link

@motoridersd commented on GitHub (Feb 25, 2023):

I have the same issue when using paths after my main domain. Works fine with the Chrome extension but matching is broken in Android 13 (Pixel 7 Pro)

@motoridersd commented on GitHub (Feb 25, 2023): I have the same issue when using paths after my main domain. Works fine with the Chrome extension but matching is broken in Android 13 (Pixel 7 Pro)
GiteaMirror commented 2025-11-26 22:49:44 -06:00
Author
Owner
Copy Link

@rg9400 commented on GitHub (Mar 26, 2023):

@clayadams5226 any update on this issue? I noticed a few others confirming this is broken on Android, and the bug request has been open for nearly a year. Thanks!

@rg9400 commented on GitHub (Mar 26, 2023): @clayadams5226 any update on this issue? I noticed a few others confirming this is broken on Android, and the bug request has been open for nearly a year. Thanks!
GiteaMirror commented 2025-11-26 22:49:44 -06:00
Author
Owner
Copy Link

@rg9400 commented on GitHub (Jul 17, 2023):

@clayadams5226 and @creyhani any update on this? It's been open for a year, and might be related to https://github.com/bitwarden/mobile/issues/578 which has been open for 4 years. This is still very cumbersome, so it would be nice to have some update on it

@rg9400 commented on GitHub (Jul 17, 2023): @clayadams5226 and @creyhani any update on this? It's been open for a year, and might be related to https://github.com/bitwarden/mobile/issues/578 which has been open for 4 years. This is still very cumbersome, so it would be nice to have some update on it
GiteaMirror commented 2025-11-26 22:49:44 -06:00
Author
Owner
Copy Link

@Dentic89 commented on GitHub (Mar 23, 2024):

Got the same issue, is there any fix yet? Attached picture from bitwarden forum describes it perfectly.

Login Screen

@Dentic89 commented on GitHub (Mar 23, 2024): Got the same issue, is there any fix yet? Attached picture from bitwarden forum describes it perfectly. ![Login Screen](https://github.com/bitwarden/mobile/assets/164643523/3a8d240a-cbd7-408b-b5ee-1c743055e5e6)
GiteaMirror commented 2025-11-26 22:49:45 -06:00
Author
Owner
Copy Link

@vvolkgang commented on GitHub (Jun 20, 2024):

Issue migrated to https://github.com/bitwarden/mobile/issues/1946

@vvolkgang commented on GitHub (Jun 20, 2024): Issue migrated to https://github.com/bitwarden/mobile/issues/1946
Sign in to join this conversation.
No Branch/Tag Specified
Branches Tags
Labels
Clear labels
app:authenticator
app:password-manager
bug
bug-passkey
customer-support
duplicate
enhancement
good first issue
help wanted
needs-reply
needs-response
pull-request
Mirrored from GitHub Pull Request
 question
No Label bug good first issue
Milestone
No items
No Milestone
Projects
Clear projects
No project
Assignees
Clear assignees
GiteaMirror ninjasurge
No Assignees
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: github-starred/android#1459
Delete Branch "%!s()"

Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?