1763570 - LastPass autofill prompt is displayed under wrong element (Sign-in button instead of the credentials text field)

Status: RESOLVED FIXED

(GeckoView :: General, defect, P2)

Description

[Petru-Mugurel Lingurar [:petru]]

From github: https://github.com/mozilla-mobile/focus-android/issues/6838.

Steps to reproduce

1. Install a password manager app (i.e. Lastpass).
2. Setup the app to have autofill rights (check the app's instructions).
3. In the password manager app, fill up some credentials for some pages (like facebook.com, or linkedin.com).
4. In Focus, go to website that requires credentials (one that has the credentials saved in the password manager app), and tap the login text field.

Expected behavior

The autofill prompt is displayed below the credentials fields.

Actual behavior

The autofill prompt is displayed below the credentials fields, sometimes hard to observe by the user.

Device information

• Android device: Lenovo Tab M10 (Android 10), Oppo Find X3 Lite (Android 11)
• Focus version: Beta 100.0.0-beta.1, Nightly 101.0a1 from 4/6
• Reproducible also on Fenix Beta 100.0.0-beta.2, Nightly 101.0a1 from 4/6
• Not reproducible on Chrome

Change performed by the Move to Bugzilla add-on.

Comment 1

[Chris Peterson [:cpeterson]]

Attachment: screenshot.png

Screenshot from the GH issue: https://github.com/mozilla-mobile/focus-android/issues/6838

In Chrome, the LastPass dropdown menu is positioned beneath the "Email or Phone" text field.

In Fenix and Focus, the LastPass dropdown menu is positioned beneath the "Sign in" button.

Is this a LastPass bug? Or is Gecko not exposing some element metadata that would allow LastPass to discover the correct element (the "Email or Phone" text field)?

Is this a recent regression?

Comment 2

[miralobontiu]

It doesn't reproduce on Focus Nightly 100.0a1 (build 360741707 with GV 100.0a1-20220315091352) with Oppo Find X3 (Android 11).

Comment 3

[miralobontiu]

Attachment: Screenshot_2022-04-08-11-19-27-89_11753d9bf2a67eec1c984b8ccb4d0671.jpg

Comment 4

[Chris Peterson [:cpeterson]]

@ Olivia: could this bug be a regression from your "GeckoView Prompts Adjustment" fix for Marionette bug 1712414? If you can't test LastPass on one of your devices, maybe you can create a Fenix or Focus test build without your fix that Mirabela can test.

@ Mirabela: is a paid LastPass account required to install LastPass and reproduce the bug? How do you recommend Olivia reproduce the bug?

Since Mirabela could reproduce the bug in Focus Beta 100.0.0-beta.1 from 4/6 but not in Focus Nightly 100.0a1 from 3/15, then the bug was introduced in Focus Nightly 100.0a1 between 3/15 and 4/4 (when Nightly 100 merged to Beta 100).

Here are all the Gecko and GeckoView code changes between 3/15 and 4/4:

https://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=d36030f3adc34dc9b756bc9aefe5b277cbf58553&tochange=1ce63246334ec627d74c38d7acd5b858c781336a

There are a lot, but I skimmed the list for keywords like "Android" or "prompt" and your "GeckoView Prompts Adjustment" fix looks suspicious.

Comment 5

[miralobontiu]

No, I don't have a paid account for LastPass.

Comment 6

[Olivia Hall [:olivia]]

Attachment: Shows content scrolling when clicking an Autofill field.

Comment 7

[Olivia Hall [:olivia]]

The bug was still present after removing the GeckoView prompts adjustment. I was able to reproduce the bug on an emulated Pixel 4 and Nexus 5X using API 30 (Android 11) using Fenix and GeckoView Example.

The issue was still present after reverting these prompt changes:

• Bug 1762543 - Race Condition When Dismissing a GeckoView Prompt in Marionette
• Bug 1708105 - [marionette] Add support for user prompts on Android.
• Bug 1712414 - GeckoView Prompts Adjustment for Marionette

I added a video to add some more information to the bug. When clicking or tabbing into the input fields, the screen shifts automatically. This occurs both with and without an onscreen keyboard.

It looks like it may have something to do with focusing into the input field and Android Autofill tries to use the old location for the input field? (The Android Autofill box is in the correct location before the content scrolls.)

Comment 8

[Olivia Hall [:olivia]]

Attachment: GeckoView extended example of navigating into field.

Comment 9

[Makoto Kato [:m_kato]]

About comment #6, I know it.

When on Fennec (bug 725018 and bug 1265551), we seem to use PanZoom:StateChange observer to wait for scroll of zoomToFocusedInput. But actually, it isn't supported on e10s environment.

I guess that BrowserChild::NotifyAPZStateChange should notify of PanZoom:StateChange with NOTHING and PANNING like widget (https://searchfox.org/mozilla-central/rev/3e21f2bb69734804d311e16b914c4efcc94bb18d/widget/android/AndroidContentController.cpp#52-63), then use this observer

Comment 10

[Chris Peterson [:cpeterson]]

Makoto says we can fix this bug in GeckoView. This is an APZ/e10s issue, not a LastPass bug. This is not a high priority because the user can still access the LastPass menu; it's just in the wrong position.

Comment 11

[Pascal Chevrel:pascalc (PTO until April 26)]

Makoto, do you have an update on the GV fix? thanks

Comment 12

[Chris Peterson [:cpeterson]]

Makoto says Gecko passes old client rect before popping up the software keyboard.

Comment 13

[Makoto Kato [:m_kato]]

I handle this at Q2 or H2.

Comment 14

[Makoto Kato [:m_kato]]

https://treeherder.mozilla.org/jobs?repo=try&revision=ea84f8fbec54ff626a7b21ef0ffc249e61f5e03f

Comment 15

[Makoto Kato [:m_kato]]

Attachment: Bug 1763570 - Wait for APZ state to set autofill information. r=#geckoview-reviewers

When setting focus to input element, Gecko sets focused element to central via
zoomToFocusedInput. So when we receives focusin event, content may be
scrolled and zoomed. To pass correct element rectangle, we have to wait until
it is completed.

Fennec added PanZoom:StateChange event to listen APZ state. So GV should use
same way.

Comment 16

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/457c6c1a18e3
Wait for APZ state to set autofill information. r=geckoview-reviewers,owlish

Comment 17

[Sandor Molnar[:smolnar]]

Backed out changeset 457c6c1a18e3 (bug 1763570) for causing layout/forms/test/test_bug644542.html

Backout link: https://hg.mozilla.org/integration/autoland/rev/b07c78b1813115361b576378bfea4a1d9c107d18

Push with failures

Failure log

TEST-FAIL | layout/forms/test/test_bug644542.html | The author of the test has indicated that flaky timeouts are expected.  Reason: untriaged
[task 2022-07-11T03:42:52.713Z] 03:42:52     INFO -  Buffered messages finished
[task 2022-07-11T03:42:52.713Z] 03:42:52  WARNING -  TEST-UNEXPECTED-FAIL | layout/forms/test/test_bug644542.html | Test timed out. -

Comment 18

[Makoto Kato [:m_kato]]

layout/forms/test/test_bug644542.html isn't failure on try build.

https://treeherder.mozilla.org/jobs?repo=try&revision=a0ef9c8d65e8e95a0375c25b668637cd2c64dbe2

Comment 19

[Makoto Kato [:m_kato]]

I make sense this failure. When navigating to other page during waiting APZ state, some tests may be failure. I shouldn't use window.setTimeout and should use nsITimer instead. And I also adds dead object check.

Comment 20

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/0ec8d08749a1
Wait for APZ state to set autofill information. r=geckoview-reviewers,owlish

Comment 21

[Cristian Tuns]

https://hg.mozilla.org/mozilla-central/rev/0ec8d08749a1