Yesterday, I was cleaning up my vault’s URIs and making sure they point to the correct login page. My plan was to use the starts with match detection option. For some reason though, it won’t when using a browser in Android where I am using the keyboard. Neither through the in line key board, nor through anything else.
URI in Bitwarden: https://www.aa.com/loyalty/login
Screenshots with match detection set to “starts with”
Screenshot match detection set to “Host”
Is this perhaps because Bitwarden doesn’t detect the “https” portion of the URI?
March 11, 2023, 5:19pm
Could you screenshot this to verify? Are you sure there is no trailing backslash, for example (
In a Chrome browser on a Windows PC, using
Starts With for the URI
https://www.aa.com/loyalty/login does work, so it may be some weird Android issue.
March 11, 2023, 10:30pm
Thanks for providing the requested information. In that case, your best hope is that someone who has experience with doing match detection on Android will stop by and help. Per the
documentation global and custom match detection options are supported in the mobile apps, so there appears to be some idiosyncrasy at play here.
I tried the exact scenario on my Google Pixel 5a (Android 13) and I had the same problem that
@Unissued7022 described. I have not tried to see if the problem exists for other websites or other URI matching options.
March 15, 2023, 11:27pm
I ran into what seems to be the same issue. The issue seems to be the combination of filling from the keyboard (as opposed to the popup), and using “Starts With”:
March 15, 2023, 11:52pm
This behavior seems to be related to
Issue #1946 on GitHub:
03:55AM - 09 Jun 22 UTC
good first issue
### 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
### Additional Context
### Operating System
### Operating System Version
Samsung S22 Ultra
### Build Version
- [X] Using a pre-release version of the application.