[Bug]: Autofill fails, when I need to unlock bitwarden.

[dholbert]

Steps to reproduce

1. Be sure your Android Bitwarden app is locked *and killed. (i.e. If you open the app, it should prompt you for master password or biometric auth; if it does so, that's good -- leave it in that state, and kill the app by swiping it offscreen from your app-switcher UI). In the event you've unlocked it, lock it via its "Settings|Lock Now" button, and then kill the app.
2. In Fenix, visit some site where Bitwarden has a saved login that you could use, e.g. in my case I'm using https://wiki.mozilla.org/index.php?title=Special:UserLogin
3. Tap the website's username field
4. Keyboard will appear, with a "Bitwarden Vault is locked" button at the top. Tap that button.
5. Authenticate with Bitwarden. It will probably then say "Items for mozilla.org" (or whatever site you're on).
6. Tap its entry for the credentials that you want to use. (This makes Bitwarden disappear and Firefox becomes foreground again.)

Expected behaviour

The username/password field should have been filled in.
Also, my keyboard should have buttons for the various matching logins in Bitwarden, now that I've unlocked it. (This is what happens if I reload at this point and focus the username or password field, i.e. if I perform the STR with Bitwarden already focused.)

Actual behaviour

The username field is still empty.
The password field has gained focus, but is also empty.
My keyboard does not have any Bitwarden buttons anymore.

Device name

Google Pixel 4a

Android version

Android 12

Firefox release type

Firefox Nightly

Firefox version

102.0a1

Device logs

No response

Additional information

Note that in Bitwarden settings, under "Auto-fill Services", I have every option enabled.

┆Issue is synchronized with this Jira Task

[dholbert]

CC @agi

[dholbert]

Not sure if it's relevant, but I notice the following in my logcat output around the time when I perform step 6 (tapping the credentials in bitwarden to automatically switch back to Firefox), when this bug happens:

W AutofillManagerServiceImpl: getFillEventHistory() called by UID 10149, but service UID is 10260
I GoogleInputMethodService: GoogleInputMethodService.onFinishInput():3182 
W ContentCaptureService: handleSendEvents() received empty list of events
W InputManager-JNI: Input channel object 'ff8531e com.x8bit.bitwarden/com.x8bit.bitwarden.MainActivity (client)' was disposed without first being removed with the input manager!

[dholbert]

Also notable, this bug reproduces most of the time for me, but occasionally I get Expected Behaviour. I think it seems more-likely-to-repro if I've killed bitwarden at the very start; I updated the STR to indicate that.

[dholbert]

Not sure if it's relevant, but I notice the following in my logcat output around the time when I perform step 6 [...] when this bug happens:

Actually, it looks like I see all that same logcat output in scenarios where I get Expected Behaviour, too. (Maybe the ContentCaptureService: handleSendEvents() received empty list of events logging might be missing when I get expected-results, though I'm also not sure if that's from my STR or just background noise.)

[dholbert]

(Also, I can reproduce in Firefox release as well, though it superficially feels like I get Expected Behaviour more of the time there. From my handful of test iterations today, it feels like this bug reproduces at least 80% of the time for me on Nightly, vs. maybe closer to 50% of the time on release. Not sure if this is due to a race condition or if it's really the same frequency and I just got lucky/unlucky in one or the other version.)

[agi]

Thanks for this bug report @dholbert I can consistently reproduce on Firefox Nightly, but interestingly not on GVE where this works as expected (even though the code is basically the same). I'll try to see if I can reproduce on Fenix debug.

[agi]

I can reproduce on Fenix debug, will update.

[agi]

Ah I see what's happening, the GeckoView receiving the autofill call doesn't contain the session (because Fenix automatically unlinks sessions when switching away) and thus it cannot autofill. But looking at the current GeckoView session is not the right thing to do anyway (as the app might switch the session under us in between onProvideAutofillStructure and autofill) so we need to keep a reference to the autofill session anyway.

[agi]

This is a race condition between setting the session back in the GeckoView instance and autofilling, hence why sometimes it works and sometimes it doesn't.

[agi]

Moved to bugzilla: https://bugzilla.mozilla.org/show_bug.cgi?id=1770010

Change performed by the Move to Bugzilla add-on.