2006761 - Autofill UI covers up fixed-position content at the bottom of the viewport (e.g. confirm/add-to-cart/proceed buttons)

Status: NEW

(Firefox for Android :: Autofill, defect)

Description

[Daniel Holbert [:dholbert]]

Attachment: testcase 1

Steps to reproduce

1. In Firefox for Android, add some autofillable address. (Go to Settings | Autofill | Manage addresses | Add address, and then be sure to type in at least a name, street-address, zip-code, and an email address)
2. View the attached testcase.
3. Follow the steps in the testcase -- first tap the textfield, then tap outside the textfield, and then try to see or press the button at the bottom of the page.

Expected behavior

Should be able to see (or scroll-to-see) the button at the bottom of the page. Probably the autofill UI should disappear when the textfield loses focus and the keyboard is dismissed.

Actual behavior

• The autofill UI sticks around even though I'm not actively editing/focusing any form fields.
• It covers up the button at the bottom of the page, which means I can't tap the button and complete whatever process I'm trying to do.
• I can't scroll to reach the button, either; it's just covered up.

Device information

• Firefox version: 148.0a1
• Android device model: Pixel 10 Pro XL, Pixel 6a
• Android OS version: 16

Any additional information?

This is related to bug 2006756. That bug is focused on us showing the autofill UI too often (or showing too much information in it); this bug is about what the autofill UI covers up, when it does show.

I ran into this bug in the wild when trying to complete a checkout process in the past few days. There was some sort of "confirm/add-to-cart" button at the bottom of the viewport, and it got covered up by the autofill UI which stuck around after I filled some form-fields manually. The only workaround that I found was to explicitly turn off autofill in Firefox settings.

Comment 1

[Daniel Holbert [:dholbert]]

Attachment: screencast of bug (button at bottom of viewport gets covered up)

Comment 2

[Daniel Holbert [:dholbert]]

Note: after a bit more testing, I've found that the autofill UI only gets offered if my saved address includes some value for at least these fields: Name, Street Address, Zip Code, and Email Address.

Name & Street Address can be a single letter ("a"), zip code can be a single digit ("1"), and the email address can be e.g. a@a (we don't offer to autofill if I put less than that).

Comment 3

[Daniel Holbert [:dholbert]]

(Adding see-also for bug 1976446, where the autofill prompt was covering up something else and we shifted its position. Not sure offhand if that's where this regressed -- maybe? -- but in any case it's a related sort of issue.)

Comment 4

[Daniel Holbert [:dholbert]]

My STR here (with the attached testcase) will only show the autofill UI and reproduce the bug as of Nightly 2025-12-04 and newer (builds with the patch for bug 1930874) -- see bug 2006756 comment 3 for details. Older builds don't offer the autofill UI on this testcase and hence don't hit the issue.

But, having said that, I assume this bug does actually go back further than that -- it just requires a different kind of testcase (perhaps with more form-fields) to trigger the autofill UI and cover up the button as in the attached testcase.

Comment 5

[Petru-Mugurel Lingurar [:petru]]

Unfortunately this is a known issue - and it has been an issue from the start.
We currently don't measure what UI elements of Fenix cover the engine view to automatically inform GeckoView about them but "manually" compute the height of the top & bottom toolbars/banners like here where we don't account for the autofill banner (and others).
Talked recently with @mstange about this, the APZ team is aware of these issues.
We do plan on improving things next year. Created now this meta to hang tickets like this to for ensuring we'll not forget about checking them.

Comment 6

[Daniel Holbert [:dholbert]]

(Note: after bug 2006756's patch lands, we'll probably need a modified testcase here -- using some other autofillable field(s), not just email -- in order to trigger the autofill UI & reproduce this bug.)