1531443 - When autofill falls back to form history it can clobber the filled value with the last autofill record result

Status: VERIFIED FIXED

(Toolkit :: Form Autofill, defect, P1)

Description

[Jason Orendorff [:jorendorff]]

In bug 1495072, I'm changing await to be about 2x faster (each await currently creates an extra Promise, for no good reason—it's redundant—and the change is to stop doing that).

This breaks some tests, including this one.

Here's a failing try run: https://treeherder.mozilla.org/#/jobs?repo=try&revision=062c8d2376f219984890a225cf8cb599215fa871&selectedJob=230358797

Comment 1

[Jason Orendorff [:jorendorff]]

MattN, the test that is failing here changed recently. Is there a likely race condition in the new code?

Comment 2

[Matthew N. [:MattN]]

This is blocking bug 1495072.

Comment 3

[Matthew N. [:MattN]]

This seems to be uncovering a real bug… the fix for bug 1439023 stopped form history from breaking but didn't stop form autofill from later also trying to autofill the selected field. The test previously saw the correct value but due to the timing change the test is now seeing the final value which is incorrect. I think I have an easy fix.

Comment 4

[Matthew N. [:MattN]]

This isn't exactly a regression since nothing was filled before bug 1439023… it's more that the fix for bug 1439023 was incomplete because the test passed when it shouldn't have.

Comment 5

[Matthew N. [:MattN]]

Attachment: Bug 1531443 - Clear the `lastProfileAutoCompleteResult` during a form history fallback search. r=jaws

Comment 6

[Matthew N. [:MattN]]

The main thing to manually test is that when you get a form history popup (no footer or "also autofills" line) on an address field then it should only ever modify the selected field and the field shouldn't get the yellow background.

STR:
browser.search.region must be "US" at browser startup time in order to have address autofill enabled.

1. Load https://luke-chang.github.io/autofill-demo/textarea_select.html
2. Submit the form with values:
   organization: Mozilla
   addressLevel2: San Francisco
   addressLevel1: California
   postalCode: 94041
   country: United States
3. After submission, open the autofill dropdown on the organization field (down arrow or typing "Mo…" etc.). An autofill popup, not a form history popup, should appear. You can identify it by the yellow "Also autofills …" line and the Preferences/Options grey footer.
4. Select the record you just submitted in #2. It should fill all the fields you saved with yellow highlights.
5. Clear the postalCode field
6. Clear the Organization field
7. Open the autocomplete popup on the organization field like in step 3 but this time you should get a form history popup/dropdown.
8. Select the entry (with mouse or keyboard) to fill that one field.

Expected result:
Only the organization field should change. It should not get a yellow highlight.
The postalCode field should remain empty.

Actual result:
The whole profile is autofilled so the postalCode field is re-filled.
The organization field gets the yellow highlight.

Comment 7

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/7cc86fd0d386
Clear the `lastProfileAutoCompleteResult` during a form history fallback search. r=jaws

Comment 8

[Andrei Ciure[:aciure]]

https://hg.mozilla.org/mozilla-central/rev/7cc86fd0d386

Comment 9

[Liz Henry (:lizzard) (privacy/fingerprinting team)]

This can still make it into beta 14 if we can verify and uplift tomorrow.

Comment 10

[Matthew N. [:MattN]]

Comment on attachment 9047497 [details]
Bug 1531443 - Clear the lastProfileAutoCompleteResult during a form history fallback search. r=jaws

Beta/Release Uplift Approval Request

• Feature/Bug causing the regression: Bug 1429718
• User impact if declined: The fix to bug 1439023 will not be good enough in some cases meaning the wrong value can get autofilled into a form field.
• Is this code covered by automated tests?: Yes
• Has the fix been verified in Nightly?: No
• Needs manual test from QE?: Yes
• If yes, steps to reproduce: See comment 6.
• List of other uplifts needed: None
• Risk to taking this patch: Low
• Why is the change risky/not risky? (and alternatives if risky): This returns to the previous behaviour for autocomplete popups not from Form Autofill. (Prior to bug 1429718)
• String changes made/needed: None

Comment 11

[Liz Henry (:lizzard) (privacy/fingerprinting team)]

Andrei, can someone from your team try to verify in time for tomorrow? Thanks!

Comment 12

[Camelia Badau [:cbadau], Desktop Test Engineering]

I've tested on Windows 7 x64, Ubuntu 18.04 x64 an macOS 10.13 using latest Nightly 67.0a1 (2019-03-05) and the issue is fixed if I following the steps from comment 6; everything looks good here.

But I see the following scenario:

1. Load https://luke-chang.github.io/autofill-demo/textarea_select.html
2. Submit the form with values:
   organization: Mozilla
   addressLevel2: San Francisco
   addressLevel1: California
   postalCode: 94041
   country: United States
3. After submission, open the autofill dropdown on the organization field. An autofill popup, not a form history popup, should appear. You can identify it by the yellow "Also autofills address" line
4. Select the record you just submitted in #2. It should fill all the fields you saved with yellow highlights.
5. Clear the addressLevel2 field and then clear the Organization field
6. Open the autocomplete popup on the organization field like in step 3.

Actual results: At step 7, I get a form history popup/dropdown (not an autofill popup).

It is expected? To get a history popup and not an autofill popup in this scenario?

Comment 13

[Matthew N. [:MattN]]

(In reply to Camelia Badau [:cbadau], Release Desktop QA from comment #12)

…
5) Clear the addressLevel2 field and then clear the Organization field
7) Open the autocomplete popup on the organization field like in step 3.

Actual results: At step 7, I get a form history popup/dropdown (not an autofill popup).

It is expected? To get a history popup and not an autofill popup in this scenario?

Yes, that is expected since you still have some other fields filled. I forget the exact rules but when I clear the postal code field then the yellow higlights are removed and I can get an autofill popup again. I think as long as you see a yellow autofilled field still, you get the form history popup. If you use the "Clear Form" dropdown option (from an autofilled field) then it will clear all filled fields and you will get the autofill popup again.

Comment 14

[Liz Henry (:lizzard) (privacy/fingerprinting team)]

Comment on attachment 9047497 [details]
Bug 1531443 - Clear the lastProfileAutoCompleteResult during a form history fallback search. r=jaws

Fix for autofill regression in 66, let's take it for beta 14.
Comment 12 and comment 13 look like close enough verification to me.

Comment 15

[Matthew N. [:MattN]]

https://hg.mozilla.org/releases/mozilla-beta/rev/533b15ae2bde

Comment 16

[Camelia Badau [:cbadau], Desktop Test Engineering]

(In reply to Matthew N. [:MattN] (PM me if requests are blocking you) from comment #13)

(In reply to Camelia Badau [:cbadau], Release Desktop QA from comment #12)

…
5) Clear the addressLevel2 field and then clear the Organization field
7) Open the autocomplete popup on the organization field like in step 3.

Actual results: At step 7, I get a form history popup/dropdown (not an autofill popup).

It is expected? To get a history popup and not an autofill popup in this scenario?

Yes, that is expected since you still have some other fields filled. I
forget the exact rules but when I clear the postal code field then the
yellow higlights are removed and I can get an autofill popup again. I think
as long as you see a yellow autofilled field still, you get the form history
popup. If you use the "Clear Form" dropdown option (from an autofilled
field) then it will clear all filled fields and you will get the autofill
popup again.

Thanks for your answer!
Marking the status-firefox67 flag as Verified.

Comment 17

[Camelia Badau [:cbadau], Desktop Test Engineering]

Verified fixed on Windows 7 x64, Ubuntu 18.04 x64 and macOS 10.13 using Firefox 66 Beta 14 (buildID: 20190307095232).