Android app match detection in browser set to starts with

grb · March 15, 2023, 11:52pm

This behavior seems to be related to Issue #1946 on GitHub:

[Android] Match Detection settings misbehaving with Inline Autofill

opened 03:55AM - 09 Jun 22 UTC

bug good first issue already-fixed

### 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 _No response_ ### Additional Context _No response_ ### Operating System Android ### Operating System Version Android 12 ### Device Samsung S22 Ultra ### Build Version 2022.05.0 (4636) ### Beta - [X] Using a pre-release version of the application.