[KnownUsernameField] Compatibility with more browsers

[contribucious]

Context

Currently, the new system allowing "email/username" field detection without "password" field, which uses the accessibility service, only works well with some browsers like Chrome.

Indeed, if the subdomain is specific like signin.example.com: no problem!
But if it's www.example.com, Bitwarden (with current entries) will assume that the browser will hide this part for comparison. (This is a new trend in browsers.)

Problem

This is only the case in some browsers (currently: Chrome, Firefox beta, etc.).

Problem (illustration with Amazon but same with PayPal for ex.)

View me ...

 

new KnownUsernameField("amazon.com", "signin", "ap_email_login"),
[...]
if (KnownUsernameFields.ContainsKey(uriKey))

➡️ Chrome ✔️ (match, because Chrome hides www.)

View me ...

 

>>> uriKey: amazon.com, uriLocalPath: /ap/signin, viewId: ap_email_login

➡️ Firefox for Android 68.x ❌ (don't match, because Firefox shows www.)

View me ...

 

>>> uriKey: www.amazon.com, uriLocalPath: /ap/signin, viewId: ap_email_login

Solution

It's therefore advisable to remove the www. part on the Bitwarden side before comparison.

This PR allows the use of this system with:

• Older versions of Chrome (+ forks) ✔️
• Firefox for Android <= 68.x (+ forks) ✔️
  💡 Current stable version at the time of writing: 68.10.0 (68.9.0 on Google Play Store)
• Some alternative browsers ✔️

➡️ Please note: The logged uriKey value will now be the one to be used in practice. So, will always return the version without www. from now on.

[contribucious]

Regarding the case of Samsung Internet Browser

Although this PR solves this problem in this browser as well, there is another problem in this browser, preventing the new system from working.

Read more ...

 

↪️ This browser hides the path.
And this is clearly visible in the logs: we'll always have uriLocalPath: / (instead of uriLocalPath: /ap/signin, in this specific example). So will never match ...

And, on the user side, there doesn't even seem to be any flags available on this subject (to force the display of the path) in the list of flags available at internet://flags (chrome://flags doesn't exist) within this browser, sadly. Even in the latest version currently available: 12.0.1.47.

[mpbw2]

I agree the new trend of hiding paths is slowly going to render this feature inoperable. It would be lovely if a viable alternative presented itself.