github-starred/android
2
0
Fork 0
mirror of https://github.com/bitwarden/android.git synced 2026-05-08 21:10:40 -05:00
Code Issues 1.1k Packages Projects Releases 122 Wiki Activity

Host Match Detection broken for URLs with ports #2217

New Issue
Open
opened 2025-11-26 23:12:03 -06:00 by GiteaMirror · 14 comments
GiteaMirror commented 2025-11-26 23:12:03 -06:00
Owner
Copy Link

Originally created by @NicholasFlamy on GitHub (Apr 22, 2025).

Steps To Reproduce

https://github.com/bitwarden/mobile/issues/2970

  1. Save an autofill item for a URL with a port.
  2. See how it behaves on sites.

Expected Result

Works correctly. Or at least works like the old app.

Actual Result

Doesn't work.

Screenshots or Videos

No response

Additional Context

No response

Build Version

2025.3.0

What server are you connecting to?

Self-host

Self-host Server Version

No response

Environment Details

No response

Issue Tracking Info

  • 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.
Originally created by @NicholasFlamy on GitHub (Apr 22, 2025). ### Steps To Reproduce https://github.com/bitwarden/mobile/issues/2970 1. Save an autofill item for a URL with a port. 2. See how it behaves on sites. ### Expected Result Works correctly. Or at least works like the old app. ### Actual Result Doesn't work. ### Screenshots or Videos _No response_ ### Additional Context _No response_ ### Build Version 2025.3.0 ### What server are you connecting to? Self-host ### Self-host Server Version _No response_ ### Environment Details _No response_ ### 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.
GiteaMirror added the app:password-managerbug labels 2025-11-26 23:12:03 -06:00
GiteaMirror commented 2025-11-26 23:12:04 -06:00
Author
Owner
Copy Link

@S-Kakar commented on GitHub (Apr 22, 2025):

Thank you for your report! We've added this to our internal board for review.
ID: PM-20513

@S-Kakar commented on GitHub (Apr 22, 2025): Thank you for your report! We've added this to our internal board for review. ID: PM-20513
GiteaMirror commented 2025-11-26 23:12:04 -06:00
Author
Owner
Copy Link

@NicholasFlamy commented on GitHub (Apr 22, 2025):

Note: #4531 is focused on Host detection not working WHICH IS A KNOWN AND REPRODUCIBLE ISSUE CAUSED BY CHROMIUM. This issue is focused on the fact that the new app behaves different from the old one.

@NicholasFlamy commented on GitHub (Apr 22, 2025): Note: #4531 is focused on Host detection not working WHICH IS A KNOWN AND REPRODUCIBLE ISSUE CAUSED BY CHROMIUM. This issue is focused on the fact that the new app behaves different from the old one.
GiteaMirror commented 2025-11-26 23:12:04 -06:00
Author
Owner
Copy Link

@NicholasFlamy commented on GitHub (Apr 22, 2025):

Big difference 1. is that leaving out the URL scheme, http:// or https://, makes the autofill not work if Match Detection is set to Host.

Big difference 2. is that Accessibility Autofill no longer handles ports. On the old app, enabling both accessibility and inline autofill meant the inline showed all options for that base domain which the accessibility button to open the Bitwarden app would open the app to just the properly mathing URLs.
(To use accessibility autofill on the new app I have to disable inline autofill. Once I do that I see that the accessibility autofill behaves the same as the inline autofill, which is incorrect).

@NicholasFlamy commented on GitHub (Apr 22, 2025): Big difference 1. is that leaving out the URL scheme, `http://` or `https://`, makes the autofill not work if Match Detection is set to Host. Big difference 2. is that Accessibility Autofill no longer handles ports. On the old app, enabling both accessibility and inline autofill meant the inline showed all options for that base domain which the accessibility button to open the Bitwarden app would open the app to just the properly mathing URLs. (To use accessibility autofill on the new app I have to disable inline autofill. Once I do that I see that the accessibility autofill behaves the same as the inline autofill, which is incorrect).
GiteaMirror commented 2025-11-26 23:12:05 -06:00
Author
Owner
Copy Link

@NicholasFlamy commented on GitHub (Apr 23, 2025):

Small, unrelated thing: Great job on the native app. It LITERALLY takes less than a 1/4 second to open to the main screen when opening it from the Android home screen.
Seriously, great job! (I would like a compact mode appearance option but overall great.)

@NicholasFlamy commented on GitHub (Apr 23, 2025): Small, unrelated thing: Great job on the native app. It LITERALLY takes less than a 1/4 second to open to the main screen when opening it from the Android home screen. Seriously, great job! (I would like a compact mode appearance option but overall great.)
GiteaMirror commented 2025-11-26 23:12:05 -06:00
Author
Owner
Copy Link

@SaintPatrck commented on GitHub (May 1, 2025):

Hi @NicholasFlamy,

There is a limitation with the Autofill framework that prevents us from matching based on port, path, and query string parameters. They are completely omitted from the request we receive. I left more details about this limitation on https://github.com/bitwarden/mobile/issues/2124#issuecomment-2839759140.

The Accessibility behavior you're describing should be resolved with #5118.

I'm not able to replicate the issue with inline autofill and accessibility being enabled at the same time. Could you elaborate on the behavior you're experiencing when both are enabled?

@SaintPatrck commented on GitHub (May 1, 2025): Hi @NicholasFlamy, There is a limitation with the Autofill framework that prevents us from matching based on port, path, and query string parameters. They are completely omitted from the request we receive. I left more details about this limitation on https://github.com/bitwarden/mobile/issues/2124#issuecomment-2839759140. The Accessibility behavior you're describing should be resolved with #5118. I'm not able to replicate the issue with inline autofill and accessibility being enabled at the same time. Could you elaborate on the behavior you're experiencing when both are enabled?
GiteaMirror commented 2025-11-26 23:12:05 -06:00
Author
Owner
Copy Link

@NicholasFlamy commented on GitHub (May 1, 2025):

The Accessibility behavior you're describing should be resolved with #5118.

I hope it does, I read the description and it seems to address both parts of the issue.

I'm not able to replicate the issue with inline autofill and accessibility being enabled at the same time. Could you elaborate on the behavior you're experiencing when both are enabled?

On the old app, when I had both enabled, I would have inline auto-fill suggestions (with Android Autofill limitations) and I would have an accessibility popup to open the Bitwarden app (it may have had autofill options but I think it sometimes simply had the open Bitwarden app button).

On the new app, inline autofill takes precedence and seems to "disable" accessibility autofill. (Without actually toggling the switch in the settings.) On the new app, I don't get accessibility autofill popups while inline autofill is enabled.

The main reason I like the old app's behavior is because I often find inline autofill to be faster, and I prefer it, but on my sites where port matters, I would tap the accessibility button to open the Bitwarden app, and it would show me the autofill options for that site with the correct port.

Edit: Here are my remedy suggestions, assuming the app does a check if both are enabled and has inline autofill take precedence: Have the app simply do both if both are enabled, if someone only wants one of the two then they can disable the other.

@NicholasFlamy commented on GitHub (May 1, 2025): > The Accessibility behavior you're describing should be resolved with [#5118](https://github.com/bitwarden/android/pull/5118). I hope it does, I read the description and it seems to address both parts of the issue. > I'm not able to replicate the issue with inline autofill and accessibility being enabled at the same time. Could you elaborate on the behavior you're experiencing when both are enabled? On the old app, when I had both enabled, I would have inline auto-fill suggestions (with Android Autofill limitations) and I would have an accessibility popup to open the Bitwarden app (it may have had autofill options but I think it sometimes simply had the open Bitwarden app button). On the new app, inline autofill takes precedence and seems to "disable" accessibility autofill. (Without actually toggling the switch in the settings.) On the new app, I don't get accessibility autofill popups while inline autofill is enabled. The main reason I like the old app's behavior is because I often find inline autofill to be faster, and I prefer it, but on my sites where port matters, I would tap the accessibility button to open the Bitwarden app, and it would show me the autofill options for that site with the correct port. Edit: Here are my remedy suggestions, assuming the app does a check if both are enabled and has inline autofill take precedence: Have the app simply do both if both are enabled, if someone only wants one of the two then they can disable the other.
GiteaMirror commented 2025-11-26 23:12:05 -06:00
Author
Owner
Copy Link

@SaintPatrck commented on GitHub (May 9, 2025):

Thanks for clarifying, @NicholasFlamy. I think I see where the disconnect is now.

The Accessibility overlay that you're expecting was omitted from the native rewrite. Accessibility autofill must now be triggered by clicking the Autofill quick tile from the notification bar. If the app is fillable (not a system app, launcher app, not explicitly blocked, etc.) and there are fillable fields on screen, Bitwarden will launch and either display matching results or prompt to create a new entry. We no longer display an overlay as part of the Accessibility service.

In the new native application, when you see the pop-up with suggestions, that's the standard Autofill Framework taking over. You're correct that the system gives inline autofill precedence over the pop-up. There are rare scenarios where inline options are displayed along with the autofill pop-up, and from my experience those are usually a result of having credentials saved in Google Password Manager and Bitwarden. The GPM results are displayed inline in the keyboard and the Bitwarden suggestions are shown in the pop-up. Due to the limitations I mentioned earlier with the Autofill framework, this means the autofill pop-up and inline suggestions are not going to mirror the exact behavior of the legacy app.

@SaintPatrck commented on GitHub (May 9, 2025): Thanks for clarifying, @NicholasFlamy. I think I see where the disconnect is now. The Accessibility overlay that you're expecting was omitted from the native rewrite. Accessibility autofill must now be triggered by clicking the Autofill quick tile from the notification bar. If the app is fillable (not a system app, launcher app, not explicitly blocked, etc.) and there are fillable fields on screen, Bitwarden will launch and either display matching results or prompt to create a new entry. We no longer display an overlay as part of the Accessibility service. In the new native application, when you see the pop-up with suggestions, that's the standard Autofill Framework taking over. You're correct that the system gives inline autofill precedence over the pop-up. There are rare scenarios where inline options are displayed along with the autofill pop-up, and from my experience those are usually a result of having credentials saved in Google Password Manager and Bitwarden. The GPM results are displayed inline in the keyboard and the Bitwarden suggestions are shown in the pop-up. Due to the limitations I mentioned earlier with the Autofill framework, this means the autofill pop-up and inline suggestions are not going to mirror the exact behavior of the legacy app.
GiteaMirror commented 2025-11-26 23:12:05 -06:00
Author
Owner
Copy Link

@NicholasFlamy commented on GitHub (May 9, 2025):

The Accessibility overlay that you're expecting was omitted from the native rewrite.

Damn, I really liked that feature because it did what Google was too incompetent to do.

@NicholasFlamy commented on GitHub (May 9, 2025): > The Accessibility overlay that you're expecting was omitted from the native rewrite. Damn, I really liked that feature because it did what Google was too incompetent to do.
GiteaMirror commented 2025-11-26 23:12:06 -06:00
Author
Owner
Copy Link

@NicholasFlamy commented on GitHub (May 9, 2025):

Due to the limitations I mentioned earlier with the Autofill framework, this means the autofill pop-up and inline suggestions are not going to mirror the exact behavior of the legacy app.

I agree. I am disappointed that the accessibility overlay wasn't implemented in the native app because that was my workaround for Google's incompetence with the Autofill framework.

@NicholasFlamy commented on GitHub (May 9, 2025): > Due to the limitations I mentioned earlier with the Autofill framework, this means the autofill pop-up and inline suggestions are not going to mirror the exact behavior of the legacy app. I agree. I am disappointed that the accessibility overlay wasn't implemented in the native app because that was my workaround for Google's incompetence with the Autofill framework.
GiteaMirror commented 2025-11-26 23:12:06 -06:00
Author
Owner
Copy Link

@masterflitzer commented on GitHub (May 27, 2025):

There is a limitation with the Autofill framework that prevents us from matching based on port, path, and query string parameters. They are completely omitted from the request we receive.

would it be possible to still show the entries that don't match exactly? because no entries showing up is kinda bad for usability

example:
when we have the url "https://example.com:4433/test" i understand that the autofill framework will only send "https://example.com" (or even just "example.com"?), so instead of not showing any entries, show the partially matching ones (only when there are no exact matches)

@masterflitzer commented on GitHub (May 27, 2025): > There is a limitation with the Autofill framework that prevents us from matching based on port, path, and query string parameters. They are completely omitted from the request we receive. would it be possible to still show the entries that don't match exactly? because no entries showing up is kinda bad for usability example: when we have the url "https://example.com:4433/test" i understand that the autofill framework will only send "https://example.com" (or even just "example.com"?), so instead of not showing any entries, show the partially matching ones (only when there are no exact matches)
GiteaMirror commented 2025-11-26 23:12:06 -06:00
Author
Owner
Copy Link

@JunoArc commented on GitHub (Sep 13, 2025):

There is a limitation with the Autofill framework that prevents us from matching based on port, path, and query string parameters. They are completely omitted from the request we receive.

would it be possible to still show the entries that don't match exactly? because no entries showing up is kinda bad for usability

example:
when we have the url "https://example.com:4433/test" i understand that the autofill framework will only send "https://example.com" (or even just "example.com"?), so instead of not showing any entries, show the partially matching ones (only when there are no exact matches)

This is how it worked in the past I think. It was listing all the passwords for the base url without the port and you had to scroll to find it.

@JunoArc commented on GitHub (Sep 13, 2025): > > There is a limitation with the Autofill framework that prevents us from matching based on port, path, and query string parameters. They are completely omitted from the request we receive. > > would it be possible to still show the entries that don't match exactly? because no entries showing up is kinda bad for usability > > example: > when we have the url "https://example.com:4433/test" i understand that the autofill framework will only send "https://example.com" (or even just "example.com"?), so instead of not showing any entries, show the partially matching ones (only when there are no exact matches) This is how it worked in the past I think. It was listing all the passwords for the base url without the port and you had to scroll to find it.
GiteaMirror commented 2025-11-26 23:12:06 -06:00
Author
Owner
Copy Link

@NicholasFlamy commented on GitHub (Sep 13, 2025):

would it be possible to still show the entries that don't match exactly?

It currently does (at least for me), at the time there was a bug that was causing it to not always show.

@NicholasFlamy commented on GitHub (Sep 13, 2025): > would it be possible to still show the entries that don't match exactly? It currently does (at least for me), at the time there was a bug that was causing it to not always show.
GiteaMirror commented 2025-11-26 23:12:07 -06:00
Author
Owner
Copy Link

@stefanheinen commented on GitHub (Nov 7, 2025):

Hey! Any progress in this?

@stefanheinen commented on GitHub (Nov 7, 2025): Hey! Any progress in this?
GiteaMirror commented 2025-11-26 23:12:07 -06:00
Author
Owner
Copy Link

@NicholasFlamy commented on GitHub (Nov 15, 2025):

Hey! Any progress in this?

You should go bug Google about their incompetence with Android Autofill.

@NicholasFlamy commented on GitHub (Nov 15, 2025): > Hey! Any progress in this? You should go bug Google about their incompetence with Android Autofill.
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 app:password-manager 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#2217
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?