LastPass autofill prompt is displayed under wrong element (Sign-in button instead of the credentials text field)
Categories
(GeckoView :: General, defect, P2)
Tracking
(firefox-esr91 unaffected, firefox99 unaffected, firefox100 wontfix, firefox101 wontfix, firefox102 wontfix, firefox103 wontfix, firefox104 fixed)
Tracking | Status | |
---|---|---|
firefox-esr91 | --- | unaffected |
firefox99 | --- | unaffected |
firefox100 | --- | wontfix |
firefox101 | --- | wontfix |
firefox102 | --- | wontfix |
firefox103 | --- | wontfix |
firefox104 | --- | fixed |
People
(Reporter: petru, Assigned: m_kato)
Details
(Keywords: regression, Whiteboard: [geckoview:2022h2?])
Attachments
(5 files)
From github: https://github.com/mozilla-mobile/focus-android/issues/6838.
Steps to reproduce
- Install a password manager app (i.e. Lastpass).
- Setup the app to have autofill rights (check the app's instructions).
- In the password manager app, fill up some credentials for some pages (like facebook.com, or linkedin.com).
- 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•3 years ago
|
||
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?
Updated•3 years ago
|
Comment 2•3 years ago
|
||
It doesn't reproduce on Focus Nightly 100.0a1 (build 360741707 with GV 100.0a1-20220315091352) with Oppo Find X3 (Android 11).
Comment 3•3 years ago
|
||
Comment 4•3 years ago
|
||
@ 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:
There are a lot, but I skimmed the list for keywords like "Android" or "prompt" and your "GeckoView Prompts Adjustment" fix looks suspicious.
Updated•3 years ago
|
Comment 5•3 years ago
|
||
No, I don't have a paid account for LastPass.
Updated•3 years ago
|
Comment 6•2 years ago
|
||
Comment 7•2 years ago
|
||
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•2 years ago
|
||
Assignee | ||
Comment 9•2 years ago
|
||
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•2 years ago
|
||
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.
Updated•2 years ago
|
Comment 11•2 years ago
|
||
Makoto, do you have an update on the GV fix? thanks
Updated•2 years ago
|
Comment 12•2 years ago
|
||
Makoto says Gecko passes old client rect before popping up the software keyboard.
Assignee | ||
Comment 13•2 years ago
|
||
I handle this at Q2 or H2.
Assignee | ||
Comment 14•2 years ago
|
||
Updated•2 years ago
|
Assignee | ||
Comment 15•2 years ago
|
||
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.
Updated•2 years ago
|
Comment 16•2 years ago
|
||
Comment 17•2 years ago
|
||
Backed out changeset 457c6c1a18e3 (bug 1763570) for causing layout/forms/test/test_bug644542.html
Backout link: https://hg.mozilla.org/integration/autoland/rev/b07c78b1813115361b576378bfea4a1d9c107d18
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. -
Assignee | ||
Comment 18•2 years ago
|
||
layout/forms/test/test_bug644542.html
isn't failure on try build.
https://treeherder.mozilla.org/jobs?repo=try&revision=a0ef9c8d65e8e95a0375c25b668637cd2c64dbe2
Assignee | ||
Comment 19•2 years ago
|
||
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•2 years ago
|
||
Comment 21•2 years ago
|
||
bugherder |
Updated•2 years ago
|
Description
•