1638311 - Selecting autocomplete suggestion changes value of <input type=hidden>

Status: RESOLVED FIXED

(GeckoView :: IME, defect, P1)

Description

[Adam Alton]

User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:77.0) Gecko/20100101 Firefox/77.0

Steps to reproduce:

1. Load a page that has a form with a hidden input followed by an email input and password input.
2. Focus the email field and select one of the auto-fill suggestions.
3. Submit the form.

Actual results:

The submitted value of the hidden input is determined by the value of the email input.

Expected results:

The value of the hidden input should be unchanged.

A video demonstrating the problem is available here: https://youtu.be/GLckM8_rYdk

Comment 1

[Adam Alton]

It's worth noting that this bug only occurs if the hidden input is before the email input in the form.

Comment 2

[Stefan Arentz | :st3fan | ⏰ EST | he/him]

Asking MattN for feedback on this one.

I don't think we will address this in Firefox (Fennec) but may in Firefox Preview (Fenix).

Comment 3

[Matthew N. [:MattN]]

I'm confused because Adam is running 78.0a1 which I believe would be a GeckoView app e.g. Fenix or GeckoView Example. See 0:28 for the view of about:debugging with the version and 1:45 showing an address bar on the bottom (didn't think that was an option on Fennec but I'm an iOS user).

I don't even know what is providing the autocomplete suggestions in that case. Is it form history? Login autocomplete is being worked on this week still (bug 1618058). Either way I doubt this is a bug in toolkit/, I suspect it's a mobile bug.

Adam, where did you install the app from and what is the name of the app?

Comment 4

[Matthew N. [:MattN]]

Adam, are those autocomplete suggestions coming from the system autofill provider? I assume so.

I suspect the problem is that the GeckoView system autofill code is exposing or filling <input type=hidden> when it shouldn't. Again, this isn't a toolkit/ issues AFAIK.

Comment 5

[Adam Alton]

Adam, where did you install the app from and what is the name of the app?

It's "Firefox Nightly for Developers (Early Access)", installed from the Google Play Store. I've taken a couple of screenshots, one from the "About Firefox" option in the menu, and one from the Google Play Store, which are here: https://www.flickr.com/photos/adamalton/shares/5jSq7k

Adam, are those autocomplete suggestions coming from the system autofill provider? I assume so.

I'm not sure, but I think they're coming from the system autofill. I've only recently installed this version of Firefox on my phone, so some of the suggestions in the auto-fill are email addresses that I've never used in this version of Firefox. Also, the way it's styled looks the same as how suggestions appear in some other native apps on my phone.

Comment 6

[Eugen Sawin [:esawin]]

Thanks for the great report, Adam! The video you've provided is really helpful. In future, it would be great if you attached the HTML document used to reproduce the issue, too.

The app you are using (Firefox Nightly) is indeed Fenix, since we are migrating Nightly and Beta Fennec (the old app) users to Fenix.
That means that the autocomplete selection you are seeing is not provided by Fenix, since that's a feature currently being worked on.

Fenix currently supports autofilling of logins, that is automatic filling of unambiguous login forms, without user interaction like the selection you are seeing. And it also provides information via the Android AutofillManager that is used by so-called AutoFill services to interact with forms.

The selection you are seeing is provided by such an AutoFill service, which is installed independently from other apps, or is pre-installed with your Android version.
You can control the system AutoFill service in your Android settings, e.g., it's Settings -> System -> Advanced -> Languages and Input on Pixel 3 with Android 10.
It would be helpful, if you could share which AutoFill service you are using.

As for the bug, this is most likely an issue in the interpretation of the information Fenix (GeckoView really) provides via the AutofillManager to the AutoFill service.
For this particular case, GeckoView sets the hidden elment's ViewStructure as enabled=false, focusable=false, focused=false, visible=false with no hint or type. The AutoFill service shouldn't fill such a structure, but apparently it does.

Knowing which AutoFill service you are using, would help us investigate this issue.

Comment 7

[Adam Alton]

In future, it would be great if you attached the HTML document used to reproduce the issue, too.

Ah yes, I should have done that, sorry!

You can control the system AutoFill service in your Android settings, e.g., it's Settings -> System -> Advanced -> Languages and Input on Pixel 3 with Android 10.
It would be helpful, if you could share which AutoFill service you are using.

The auto-fill service on my phone is just called "Google" (and is shown with the Google logo).

Comment 8

[Emily Toop (:fluffyemily)]

This needs some investigation

Comment 9

[Eugen Sawin [:esawin]]

There are two ways to handle this issue:

1. Don't expose non-editable elements to the AutofillManager at all. This may break some heuristics/ML-based autofill models.
2. Ignore autofill requests on non-editable elements. This would break autofill services that insist on filling only the wrong element.

I think 2. is the safer route.

Comment 10

[Eugen Sawin [:esawin]]

Attachment: Bug 1638311 - [1.1] Ignore input type=hidden elements for autofill.

Comment 11

[Matthew N. [:MattN]]

(In reply to Eugen Sawin [:esawin] from comment #9)

1. Don't expose non-editable elements to the AutofillManager at all. This may break some heuristics/ML-based autofill models.

What I had suggested was a middle-ground: Non-editable isn't the right criteria IMO. We could always exclude type=hidden but include non-editable such as @readonly and @disabled.

Comment 12

[Eugen Sawin [:esawin]]

(In reply to Matthew N. [:MattN] from comment #11)

(In reply to Eugen Sawin [:esawin] from comment #9)

1. Don't expose non-editable elements to the AutofillManager at all. This may break some heuristics/ML-based autofill models.

What I had suggested was a middle-ground: Non-editable isn't the right criteria IMO. We could always exclude type=hidden but include non-editable such as @readonly and @disabled.

I've just discussed this issue with jhugman and it looks like we can't exclude hidden elements from autofilling, since some login pages (Google) rely on it.
We need some other filter, e.g., hidden with no username/password hint.

Comment 13

[Matthew N. [:MattN]]

<input type=hidden> != <input hidden> and I'm not sure if you understand that or are conflating two things?

Comment 14

[Matthew N. [:MattN]]

The toolkit password manager always excludes <input type=hidden> and that hasn't been a problem. <input hidden> and things specific to visibility are a different story.

Comment 15

[Eugen Sawin [:esawin]]

(In reply to Matthew N. [:MattN] from comment #14)

The toolkit password manager always excludes <input type=hidden> and that hasn't been a problem. <input hidden> and things specific to visibility are a different story.

I've inspected some login sites, including https://accounts.google.com and couldn't find a case with a hidden password field of type=hidden. I think it's safe to exclude such elements from reporting.

What I had suggested was a middle-ground: Non-editable isn't the right criteria IMO. We could always exclude type=hidden but include non-editable such as @readonly and @disabled.

Sorry for the confusion, I was referring to the editable concept within the GV implementation, which only depends on the type.

Comment 16

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/636ed08495b5
[1.1] Ignore input type=hidden elements for autofill. r=geckoview-reviewers,MattN,agi

Comment 17

[Bogdan Tara[:bogdan_tara | bogdant]]

https://hg.mozilla.org/mozilla-central/rev/636ed08495b5

Comment 18

[Chris Peterson [:cpeterson]]

Moving some input bugs to the new GeckoView::IME component.