Closed Bug 1436793 Opened 7 years ago Closed 2 years ago

Don't autofill in @disabled form fields

Categories

(Toolkit :: Form Autofill, defect, P2)

58 Branch
defect

Tracking

()

VERIFIED FIXED
102 Branch
Tracking Status
firefox102 --- verified

People

(Reporter: fr.maximilian.m.dean, Assigned: tgiles)

References

(Blocks 2 open bugs)

Details

(Keywords: parity-chrome, parity-safari)

Attachments

(4 files)

Attached image Buzilla test form.jpg
User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:58.0) Gecko/20100101 Firefox/58.0 Build ID: 20180206200532 Steps to reproduce: 1. In Firefox preferences under FireFox account make sure that the option "Autofill Addresses" is checked. 2. Go to this link (created specifically to replicate without using other forms on the internet): http://www.novenamasses.org/firefox-autofill-bug-test-form/ 3. Fill out the form (you can use any email address, even fake, just be prepared to enter it again a second time) selecting "Yes" to entering an address (random characters is fine) and click submit 4. Now fill out the form again using the same email address you entered previously. After you enter (or select) the email address and select "Yes" for entering the address, the form should fill out automatically. Click submit. 5. You can also try changing the name or city and leaving the rest the same just to see what happens with autofill entries versus new entries. Actual results: Every entry under the "shipping address" using the autofill shows "Please enter a valid input" in red underneath (as if these slots were blank). See screenshot to see what's happening. If one of the slots is changed (like the city or name, etc.) then the slots with autofill receive the invalid message but the altered ones do not. Expected results: The form should submit and the info should be accepted as valid (like the first entry). Some notes: 1. In experimenting I noticed that this problem only happens for the entries after conditional logic. In other words, if the form does not have the question "Would you be so kind as to enter an address?" but automatically showed the shipping address to be filled out then everything would work fine. On my website about 30% of the people choose NOT to have a card mailed to them and would prefer not to have to fill out a shipping address at all - so on all of my forms I only show the shipping address if they select "yes, please send a card" and this is when the Firefox Autofill option fails 2. I tried the autofill on a Google form and it works fine - but there is no conditional logic in a Google form - so it seems to have something to do with conditional logic. 3. I'm using Firefox 58 on a Mac OS 10.11.6 in case that matters.
One more detail that might help... Using the form noted above http://www.novenamasses.org/firefox-autofill-bug-test-form/ if I click "Yes" before entering the email address then everything works perfectly with the autofill; if I enter the email address in first (which is the logical sequence) then when I click "Yes" the autofill entries come back as invalid. So the bug seems to be linked to Firefox autofill when conditional logic is used after it has been triggered. Or, put another way, if I take care of the conditional logic before using Firefox autofill then everything works fine.
Another update... On the link above I created a second form using another plugin developer (2nd form is underneath). Results, Firefox autofill does not detect blanks to fill in and doesn't activate until after clicking yes. Functions fine after clicking yes and using autofill. I'm not sure what that shows, but it seems to be connected to how the first form/plugin hides the fields before the conditional logic question is answered and how Firefox autofill functions in that scenario.
Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:60.0) Gecko/20100101 Firefox/60.0 Build ID: 20180212220112 Managed to reproduce this issue on Nightly 60.0a1 (2018-02-12) on Windows 10 x64.
Status: UNCONFIRMED → NEW
Component: Untriaged → Form Autofill
Ever confirmed: true
OS: Unspecified → All
Product: Firefox → Toolkit
Hardware: Unspecified → All
Here is a screen video of what's happening - it only happens on the first form/plugin (by Powr) and not on the second one (by Caldera). https://www.dropbox.com/s/qsptronftji85gi/Screen%20Recording%202.mov?dl=0
Thanks for the report and the test form. Can you attach a minimal HTML test case as a Bugzilla attachment so it's easier to narrow down? https://bugzilla.mozilla.org/attachment.cgi?bugid=1443042&action=enter Thanks! Btw. I suspect the issue is that the site is not listening for events on the <input>s properly or at the right time.
Flags: needinfo?(fr.maximilian.m.dean)
I got an email from the reporter and I'm replying to them.
Have we had any response Matt? The reporter has created a test form linked in comment #0 (thanks for that!), but it has a lot of dependencies which make it a bit awkward to work with. It would be great to pare this down to just the code that demonstrates the problem. Also, an attached file isn't vulnerable to link-rot, so the bug contains the necessary information in the years to come.
Flags: needinfo?(MattN+bmo)
(In reply to Sam Foster [:sfoster] from comment #7) > Have we had any response Matt? No, the response is supposed to be on the bug as a reduced test case.
Flags: needinfo?(MattN+bmo)
I'll have a go at making a reduced test case for this so we can make a determination on where to go next with this.
Flags: needinfo?(sfoster)
Matthew & Sam, Thanks for following up on this and sorry for not responding. The bug is in the top form; the second form is a plugin form from a different company and works fine. So the conflict is between Mozilla and the 1st form, the Powr form plugin. Since it is a plugin there is no real short code that I can "reveal" to you - I just inserted the plugin on WP and published it. Steps to reproduce (with link to page in #2): 1. In Firefox preferences under FireFox account make sure that the option "Autofill Addresses" is checked. 2. Go to this link (created specifically to replicate without using other forms on the internet): https://www.novenamasses.org/firefox-autofill-bug-test-form/ 3. Fill out the form (you can use any email address, even fake, just be prepared to enter it again a second time) selecting "Yes" to entering an address (random characters is fine) and click submit 4. Now fill out the form again using the same email address you entered previously. After you enter (or select) the email address and select "Yes" for entering the address, the form should fill out automatically. Click submit. 5. You can also try changing the name or city and leaving the rest the same just to see what happens with autofill entries versus new entries.
Flags: needinfo?(fr.maximilian.m.dean)
This is a reduced test case for the issue as I've understood it: the shipping address fields are initially display:none and disabled, but are shown and enabled when the user clicks the radio button. Form autofill seems to have no problem filling in these conditionally displayed and un-disabled fields. Perhaps the issue is the highlighting of their state that is done by the form builder library? I've added something like this, triggered by a input event handler on the form. This reproduces the issue - form autofill doesnt cause an input event to fire, so the isValid handler doesnt run, leaving fields in a visually "invalid" state even though they have valid values after autofill. fr.maximilian.m.dean: Does that sound like the issue you are experiencing?
Flags: needinfo?(sfoster) → needinfo?(fr.maximilian.m.dean)
Yes, that was the problem. I did notice that the fields were highlighted when the autofill option was on. I think you have your finger right on the issue: "form autofill doesn't cause an input event to fire." As a bit of background, I had received a few complaints about the problem from my users - all who had the problem were using Firefox (and I'm presuming their "autofill" feature was on). I tried on Safari and Explorer and had no issues; I also tried using a different form plugin and had no problem on Firefox. So it was very specifically Firefox with autofill on and conditional logic on plugin forms from Powr Forms.
Flags: needinfo?(fr.maximilian.m.dean)
(In reply to fr.maximilian.m.dean from comment #12) > I think you have your finger right on the > issue: "form autofill doesn't cause an input event to fire." Form Autofill does dispatch an "input" event on changed fields *but* I realized that the hidden fields are marked as disabled so the event isn't dispatched there. Either we shouldn't fill @disabled fields or we should dispatch the events anyways. We should check what the HTML spec and other browsers do and match them for compat.
HTML Spec text: > The autocompletion mechanism must be implemented by the user agent acting as if the user had modified the control's data, and > must be done at a time where the element is mutable (e.g. just after the element has been inserted into the document, or when > the user agent stops parsing). User agents must only prefill controls using values that the user could have entered. https://html.spec.whatwg.org/multipage/form-control-infrastructure.html#autofill-processing-model I also tested in Safari 11.1.1 and Chrome 68.0.3440.42 and they don't modify @disabled fields so I think that's what we need to do. We had a meta bug (bug 1020819) to track honouring various attributes but it didn't get completed. They also don't consider disabled fields for their threshold of whether to autofill or just do form history.
Blocks: 1020819
Priority: -- → P2
Summary: Form Autofill creating invalid inputs in forms after conditional logic → Don't autofill in @disabled form fields
Assignee: nobody → tgiles
Status: NEW → ASSIGNED
Blocks: 1766442
Pushed by tgiles@mozilla.com: https://hg.mozilla.org/integration/autoland/rev/c2b1e5db15ad Don't autofill disabled fields. r=sgalich,dimi
Status: ASSIGNED → RESOLVED
Closed: 2 years ago
Resolution: --- → FIXED
Target Milestone: --- → 102 Branch

Reproduced with Fx 97.0a1 (2022-01-01) on Windows 10 (using the steps from the duplicate bug).
Verified fixed with Fx 103.0a1 (2022-06-06) and Fx 102.0b4 on Windows 10, macOS 12.1 and Ubuntu 20.04.

Status: RESOLVED → VERIFIED
Flags: qe-verify+
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: