Host Match Detection broken for URLs with ports

[NicholasFlamy]

Steps To Reproduce

bitwarden/mobile#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.

[S-Kakar]

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

[NicholasFlamy]

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]

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]

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.)

[SaintPatrck]

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 bitwarden/mobile#2124 (comment).

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?

[NicholasFlamy]

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.

[SaintPatrck]

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.

[NicholasFlamy]

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]

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.

[masterflitzer]

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)

[JunoArc]

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.