github-starred/android
2
0
Fork 0
mirror of https://github.com/bitwarden/android.git synced 2026-03-24 23:32:29 -05:00
Code Issues 144 Packages Projects Releases 118 Wiki Activity

iOS keyboard AutoFill disregards URI #1388

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

Originally created by @bobfatherx on GitHub (Dec 11, 2021).

Steps To Reproduce

  1. Enable Bitwarden AutoFill in Settings
  2. Configure subdomains (e.g., site1.myFQDN.com, site2.myFQDN.com, etc.)
  3. Create Bitwarden login and password entries for each subdomain, enter a URI, and set URI match to ‘starts with’
  4. Navigate to site1, site2, and inspect the keyboard AutoFill suggestion that appears to the left of the key that invokes BitWarden’s pop up

Expected Result

AutoFill suggestion should use the URI match to suggest the matching login credentials.

Actual Result

AutoFill suggestion ignores URI and suggests the login credentials of the first alphabetical Bitwarden item with a matching host. However, clicking the key invokes the Bitwarden pop up that properly matches the subdomain. See photo examples.

Screenshots or Videos

Keyboard AutoFill displaying bw.FQDN.space instead of blueiris.FQDN.space because in the vault, accordingly, the items are named ‘Home - Bitwarden’ and ‘Home - Blue Iris’

Clicking the Bitwarden key pops up the correct site, as does using the iOS share sheet (thanks for fixing the share sheet access in the recent update!)

Additional Context

No response

Operating System

iOS

Operating System Version

15.1

Device

iPad, iPhone

Build Version

Version: 2.15.0 (1225)

Beta

  • Using a pre-release version of the application.
Originally created by @bobfatherx on GitHub (Dec 11, 2021). ### Steps To Reproduce 1. Enable Bitwarden AutoFill in Settings 2. Configure subdomains (e.g., site1.myFQDN.com, site2.myFQDN.com, etc.) 3. Create Bitwarden login and password entries for each subdomain, enter a URI, and set URI match to ‘starts with’ 4. Navigate to site1, site2, and inspect the keyboard AutoFill suggestion that appears to the left of the key that invokes BitWarden’s pop up ### Expected Result AutoFill suggestion should use the URI match to suggest the matching login credentials. ### Actual Result AutoFill suggestion ignores URI and suggests the login credentials of the first alphabetical Bitwarden item with a matching host. However, clicking the key invokes the Bitwarden pop up that properly matches the subdomain. See photo examples. ### Screenshots or Videos Keyboard AutoFill displaying bw.FQDN.space instead of blueiris.FQDN.space because in the vault, accordingly, the items are named ‘Home - Bitwarden’ and ‘Home - Blue Iris’ ![](https://i.imgur.com/NeaHkHl.jpg) Clicking the Bitwarden key pops up the correct site, as does using the iOS share sheet (thanks for fixing the share sheet access in the recent update!) ![](https://i.imgur.com/PoyIwvr.jpg) ### Additional Context _No response_ ### Operating System iOS ### Operating System Version 15.1 ### Device iPad, iPhone ### Build Version Version: 2.15.0 (1225) ### Beta - [ ] Using a pre-release version of the application.
GiteaMirror added the bug label 2025-11-26 22:47:06 -06:00
GiteaMirror commented 2025-11-26 22:47:07 -06:00
Author
Owner
Copy Link

@guyyst commented on GitHub (Jan 17, 2022):

I'm not sure what your exact setup is, but after playing around with different configurations for a while I think I know what's happening. It seems like the iOS autofill is only looking at the first URI for any login entry.

When I set up myFQDN.com, site1.myFQDN.com and site2.myFQDN.com with the respective URIs and 'starts with' match detection at the first URI position, everything works fine. I get the immediate suggestion of the correct login that only requires one tap to continue: https://i.imgur.com/KdU0al5.png

But when, for example, I set up the site1.myFQDN.com login with https://site1.myFQDN.com as the second URI entry and something else as the first, iOS doesn't immediately match the login.

Again, I tested this as much as I could with my setup and haven't confirmed this suspicion by looking at the code.

@guyyst commented on GitHub (Jan 17, 2022): I'm not sure what your exact setup is, but after playing around with different configurations for a while I *think* I know what's happening. It seems like the iOS autofill is only looking at the first URI for any login entry. When I set up `myFQDN.com`, `site1.myFQDN.com` and `site2.myFQDN.com` with the respective URIs and 'starts with' match detection at the first URI position, everything works fine. I get the immediate suggestion of the correct login that only requires one tap to continue: https://i.imgur.com/KdU0al5.png But when, for example, I set up the `site1.myFQDN.com` login with `https://site1.myFQDN.com` as the *second* URI entry and something else as the first, iOS doesn't immediately match the login. Again, I tested this as much as I could with my setup and haven't confirmed this suspicion by looking at the code.
GiteaMirror commented 2025-11-26 22:47:07 -06:00
Author
Owner
Copy Link

@bobfatherx commented on GitHub (Jan 17, 2022):

Thanks for playing around with it. I can also confirm that my issue appears to have stemmed from the first URI being for an internal IP and the second URI being for a reverse proxied host. After moving the reverse proxy host to the first URI position, sites now populate the correct login from the iOS keyboard pop up.

@bobfatherx commented on GitHub (Jan 17, 2022): Thanks for playing around with it. I can also confirm that my issue appears to have stemmed from the first URI being for an internal IP and the second URI being for a reverse proxied host. After moving the reverse proxy host to the first URI position, sites now populate the correct login from the iOS keyboard pop up.
GiteaMirror commented 2025-11-26 22:47:07 -06:00
Author
Owner
Copy Link

@guyyst commented on GitHub (Jan 17, 2022):

[ ... ] the first URI being for an internal IP and the second URI being for a reverse proxied host.

Yeah same here. It's not a perfect solution since I now don't get an automatic completion on iOS for the internal IP, but since I hardly ever access that after setting up the proxy it's fine.

@guyyst commented on GitHub (Jan 17, 2022): > [ ... ] the first URI being for an internal IP and the second URI being for a reverse proxied host. Yeah same here. It's not a perfect solution since I now don't get an automatic completion on iOS for the internal IP, but since I hardly ever access that after setting up the proxy it's fine.
GiteaMirror commented 2025-11-26 22:47:07 -06:00
Author
Owner
Copy Link

@snab43 commented on GitHub (Feb 20, 2022):

Currently having this issue with localhost:port. I have a server on http://192.168.1.100 and a bunch of docker containers all the same IP but different port numbers at the end. So an example URL would be https://192.168.1.100:8181. I set them to URI match to “host”. On my desktop it matches everything perfectly. Only the login for that docker container shows. However, on iOS the wrong one is suggested. And the issue is that even when hitting the key icon to see the list of every login, I can’t tell what’s the right one because the majority of them have the username “admin”.

@snab43 commented on GitHub (Feb 20, 2022): Currently having this issue with localhost:port. I have a server on http://192.168.1.100 and a bunch of docker containers all the same IP but different port numbers at the end. So an example URL would be https://192.168.1.100:8181. I set them to URI match to “host”. On my desktop it matches everything perfectly. Only the login for that docker container shows. However, on iOS the wrong one is suggested. And the issue is that even when hitting the key icon to see the list of every login, I can’t tell what’s the right one because the majority of them have the username “admin”.
GiteaMirror commented 2025-11-26 22:47:07 -06:00
Author
Owner
Copy Link

@linedpaper commented on GitHub (Apr 23, 2023):

Having this issue too. For me they are different entries and the match detection is set to host. It appears to not respect this and shows me every entry for the domain.

@linedpaper commented on GitHub (Apr 23, 2023): Having this issue too. For me they are different entries and the match detection is set to host. It appears to not respect this and shows me every entry for the domain.
GiteaMirror commented 2025-11-26 22:47:07 -06:00
Author
Owner
Copy Link

@gmcinalli commented on GitHub (Apr 23, 2023):

@linedpaper Try the “starts with” matching.

@gmcinalli commented on GitHub (Apr 23, 2023): @linedpaper Try the “starts with” matching.
GiteaMirror commented 2025-11-26 22:47:09 -06:00
Author
Owner
Copy Link

@linedpaper commented on GitHub (Apr 25, 2023):

@gmcinalli Thanks, that's a great workaround, but this bug has been here for so long, why can't the actual issue get fixed?

@linedpaper commented on GitHub (Apr 25, 2023): @gmcinalli Thanks, that's a great workaround, but this bug has been here for so long, why can't the actual issue get fixed?
GiteaMirror commented 2025-11-26 22:47:11 -06:00
Author
Owner
Copy Link

@Gerardv514 commented on GitHub (Aug 28, 2023):

Signed up to say I’m having the same issue. The auto fill above keyboard isn’t correct, iOS chrome shows just one incorrect match. iOS safari shows same incorrect as well but you can click open the menu and it shows all subdomains. If I click the password key on chrome, which opens a pop up of bitwarden, there it will return one exact correct match.

@Gerardv514 commented on GitHub (Aug 28, 2023): Signed up to say I’m having the same issue. The auto fill above keyboard isn’t correct, iOS chrome shows just one incorrect match. iOS safari shows same incorrect as well but you can click open the menu and it shows all subdomains. If I click the password key on chrome, which opens a pop up of bitwarden, there it will return one exact correct match.
GiteaMirror commented 2025-11-26 22:47:13 -06:00
Author
Owner
Copy Link

@katosabi commented on GitHub (Oct 4, 2023):

I too have this issue; guyyst's suggestion to put the FQDN URI first makes the first match work correctly.

@katosabi commented on GitHub (Oct 4, 2023): I too have this issue; guyyst's suggestion to put the FQDN URI first makes the first match work correctly.
GiteaMirror commented 2025-11-26 22:47:15 -06:00
Author
Owner
Copy Link

@Gerardv514 commented on GitHub (Nov 21, 2023):

@dwbit can this be pushed to the team to review? This has been a problem for a while now, and I am not able to resolve by setting the FQDN uri as the first one in order.

@Gerardv514 commented on GitHub (Nov 21, 2023): @dwbit can this be pushed to the team to review? This has been a problem for a while now, and I am not able to resolve by setting the FQDN uri as the first one in order.
GiteaMirror commented 2025-11-26 22:47:17 -06:00
Author
Owner
Copy Link

@Gerardv514 commented on GitHub (Nov 22, 2023):

@Krychaz can you reproduce this issue? Been opened for almost 2 years and it’s very annoying

@Gerardv514 commented on GitHub (Nov 22, 2023): @Krychaz can you reproduce this issue? Been opened for almost 2 years and it’s very annoying
GiteaMirror commented 2025-11-26 22:47:20 -06:00
Author
Owner
Copy Link

@Gerardv514 commented on GitHub (Nov 27, 2023):

Hi @djsmith85 can you reproduce this issue? Been opened for almost 2 years and it’s very annoying

@Gerardv514 commented on GitHub (Nov 27, 2023): Hi @djsmith85 can you reproduce this issue? Been opened for almost 2 years and it’s very annoying
GiteaMirror commented 2025-11-26 22:47:22 -06:00
Author
Owner
Copy Link

@SergeantConfused commented on GitHub (Nov 28, 2023):

Hello everyone,

Thank you all for your contributions and input. The Auto-Fill suggestion on iOS uses (Base domain) as its URI match detection regardless of what the URI match detection is set to within the vault item, and that is the expected behaviour on iOS and we also mention that here; I have communicated internally about this matter and this appears to be the way iOS operates and it cannot be adjusted.

I hope this clarifies everything, and I thank you in advance for your understanding. I will now proceed and close this GitHub thread.

All the best,

@SergeantConfused commented on GitHub (Nov 28, 2023): Hello everyone, Thank you all for your contributions and input. The Auto-Fill suggestion on iOS uses (Base domain) as its URI match detection regardless of what the URI match detection is set to within the vault item, and that is the expected behaviour on iOS and we also mention that [here](https://bitwarden.com/help/uri-match-detection/#host); I have communicated internally about this matter and this appears to be the way iOS operates and it cannot be adjusted. I hope this clarifies everything, and I thank you in advance for your understanding. I will now proceed and close this GitHub thread. All the best,
GiteaMirror commented 2025-11-26 22:47:23 -06:00
Author
Owner
Copy Link

@Gerardv514 commented on GitHub (Dec 7, 2023):

@SergeantConfused this makes no sense since apples’ built in keychain has the ability to utilize subdomains.

I switched my autofill iOS option from bitwarden to keychain in iOS settings. The iOS keyboard can properly detect and match each separate sub domain.

I’m also pretty sure at one point i never had an issue with this when I first started using bitwarden.

Where does the limitation then fall?

@Gerardv514 commented on GitHub (Dec 7, 2023): @SergeantConfused this makes no sense since apples’ built in keychain has the ability to utilize subdomains. I switched my autofill iOS option from bitwarden to keychain in iOS settings. The iOS keyboard can properly detect and match each separate sub domain. I’m also pretty sure at one point i never had an issue with this when I first started using bitwarden. Where does the limitation then fall?
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
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#1388
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?