Closed Bug 1899085 Opened 3 months ago Closed 1 month ago

Firefox URL masking breaks BitWarden autofill

Categories

(Fenix :: Autofill, defect, P1)

All
Android
defect

Tracking

(firefox130 ?, firefox131 unaffected)

RESOLVED WORKSFORME
Tracking Status
firefox130 --- ?
firefox131 --- unaffected

People

(Reporter: tech4pwd, Assigned: petru)

References

(Blocks 1 open bug, Regression)

Details

(Keywords: regression, Whiteboard: [avocado sprint])

Attachments

(2 files, 1 obsolete file)

User Agent: Mozilla/5.0 (Android 14; Mobile; rv:128.0) Gecko/128.0 Firefox/128.0

Steps to reproduce:

I have a hunch of services at
raspberrypi.local:1010
raspberrypi.local:2020
raspberrypi.local:3030
raspberrypi.local:4040
raspberrypi.local:5050

And have them all saved into BitWarden as such. I have set the match detection on each one to HOST.

  1. So when I go to any of the above services
  2. And BitWarden offers the popup
  3. I unlock BitWarden with my fingerprint

Actual results:

Firefox isn't sending BitWarden the right info and so the matching is off

Expected results:

Firefox should be sending BitWarden enough info so that it can match passwords based on user selected matching criteria.

I have confirmed this bug in nightly and RTM. Also that it's a non issue in Vivaldi.

Component: General → Autofill

Are you able to see what info Firefox is sending BitWarden?

Severity: -- → S3
Flags: needinfo?(tech4pwd)
Priority: -- → P3

(In reply to Jeff Boek [:boek] from comment #1)

Are you able to see what info Firefox is sending BitWarden?

It's just my normal phone, so not really. It just seems Firefox is just sending a plain domain, but I can't confirm.

Flags: needinfo?(tech4pwd)

Jeff, have you managed to uncover any information about this by any chance?

Flags: needinfo?(jboek)

So I suspect that this bug is a result of Firefox only displaying the domain. Something which I feel should be a user preference. If it was at least an about:config preference, I could test it, but I can't even find the original bug. Anyway, having just set up Apprise, I notice that it checks the URL of the page to provide the API key, however with it being hidden in Firefox, it can't provide it. If the same is happening with BitWarden, that explains the issue faced here.

Flags: needinfo?(jboek) → needinfo?(matt.tingen)
Flags: needinfo?(matt.tingen)
Summary: Firefox doesn't play nice with BitWarden → Firefox URL masking breaks BitWarden autofill
Flags: needinfo?(matt.tingen)
Flags: needinfo?(jboek)

I'm assuming the wrong Matt got tagged here. Let me know if there is something I can provide here.

Flags: needinfo?(matt.tingen) → needinfo?(mtighe)

(In reply to Matt Tingen from comment #5)

I'm assuming the wrong Matt got tagged here. Let me know if there is something I can provide here.

Oops, sorry about that and thank you very much.

(In reply to Matt Tingen from comment #5)

I'm assuming the wrong Matt got tagged here. Let me know if there is something I can provide here.

Oops, sorry about that and thank you very much.

Blocks: 1891525
Keywords: regression
Regressed by: 1891525

Paul, are able to reproduce this bug in the latest Firefox Android Nightly builds (version 130.0a1)? We've fixed a bunch of bugs in the new toolbar and enabled the new toolbar in Nightly (only for now).

Blocks: android-toolbar-phase-1-beta
No longer blocks: 1891525
Priority: P3 → P1

(In reply to Chris Peterson [:cpeterson] from comment #8)

Paul, are able to reproduce this bug in the latest Firefox Android Nightly builds (version 130.0a1)? We've fixed a bunch of bugs in the new toolbar and enabled the new toolbar in Nightly (only for now).

Hi Chris, yep. I'm running Nightly on three devices.

Pixel 8 Pro: New toolbar on, menu redesign off.
Pixel 6 XL: New toolbar on, menu redesign on.
Lenovo P12 Tablet: New toolbar on, menu redesign on (even though it's still the old menu on tablet)

Needless to say, this bug is showing on all three devices. I've tried to provide more info but it's beyond my technical ability.

I've also tried to raise the issue with BitWarden, to no avail.

Blocks: 1858202
Flags: needinfo?(mtighe)

There is a bit of back and forth so I want to confirm that Paul's comment 4 is correct.

This is a regression because of the new toolbar that only shows the domain + TLD now, so Bitwarden cannot find the URL to know which one to provide for autofill. This will be a bug in Fenix and all the forks that you see in this list: https://github.com/bitwarden/mobile/blob/70de8245fee8e1fbd47204547774683e74253bc3/src/App/Platforms/Android/Accessibility/AccessibilityHelpers.cs#L117-L127

Removed this from the meta "TLC" because it's a regression and we should fix this instead of punting it to a meta that is not prioritized.

This has been fixed lately as a part of Bug 1907373

Flags: needinfo?(jboek)

Following up on Sarah's comment
If this was a regression because of showing just the TLD, functionality which has now been reverted
@Paul can you confirm the issue does not reproduce anymore for you with the latest Nightly?

Flags: needinfo?(tech4pwd)
Whiteboard: [avocado sprint]

(In reply to Petru-Mugurel Lingurar [:petru] from comment #12)

Following up on Sarah's comment
If this was a regression because of showing just the TLD, functionality which has now been reverted
@Paul can you confirm the issue does not reproduce anymore for you with the latest Nightly?

I can confirm that, as :skhan said, bug 1907373 is fixed.

But unfortunately BitWarden still is unable to match. It was working for a few days last week, so I'm unable to say or even surmise what broke it again.

Sorry, not the most helpful response. But as per the original report, it's fixed.

Flags: needinfo?(tech4pwd)
Assignee: nobody → petru
Status: UNCONFIRMED → ASSIGNED
Ever confirmed: true
Attached video BitwardenBaseDomainMatching.mp4 (obsolete) —

Trying to to understand what happens I first went with using Base domain matching which as pointed in the official documentation will not show a match.

I don't have a raspberry around but I have my HA server running.
Similar to accessing raspberrypi.local:3030 I tried accessing homeassistant.local:8123 .
Saw that Bitwarden (as expected) does not infer the domain in either Chrome or latest Firefox Nightly.

https://bugzilla.mozilla.org/attachment.cgi?id=9418071

After which I switched to use Host matching as recommended by Bitwarden for local TLDs.
And saw that matching and autofill does work in latest Firefox Nightly.

So not sure there is anything more for us to do.

If it still does not work for you Paul can you post a video similar to mine from https://bugzilla.mozilla.org/attachment.cgi?id=9418071 to showcase what is inferred in other browsers vs latest Firefox?

Flags: needinfo?(tech4pwd)

New video with "Allow screen capture" for Bitwarden.

Attachment #9418068 - Attachment is obsolete: true

I can confirm uniform behavior between Firefox and Vivaldi.

I suspect any outstanding issues are on BitWarden's side at this point.

Flags: needinfo?(tech4pwd)

Thank you for the update!
Might worth opening a new ticket @ Bitwarden also.
As another user of it I do appreciate how close to the community the developers from Bitwarden are also.

For now I'll close this ticket as "WORKSFORME" .
Sorry for the issues experienced and thank you for the support in discovering the root cause!

Status: ASSIGNED → RESOLVED
Closed: 1 month ago
Resolution: --- → WORKSFORME

Thank you for your hard work everyone.

You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: