Skip to content

Host Match Detection broken for URLs with ports #5084

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Open
1 task done
NicholasFlamy opened this issue Apr 22, 2025 · 9 comments
Open
1 task done

Host Match Detection broken for URLs with ports #5084

NicholasFlamy opened this issue Apr 22, 2025 · 9 comments

Comments

@NicholasFlamy
Copy link

NicholasFlamy commented Apr 22, 2025

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
Copy link

S-Kakar commented Apr 22, 2025

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

@NicholasFlamy
Copy link
Author

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
Copy link
Author

NicholasFlamy commented 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
Copy link
Author

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
Copy link
Contributor

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
Copy link
Author

NicholasFlamy commented 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.

@SaintPatrck
Copy link
Contributor

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
Copy link
Author

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
Copy link
Author

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

3 participants