1904593 - [CA][leons.ca] Need to better handle when a form field's value is modified after it has been autofilled

Status: VERIFIED FIXED

(Toolkit :: Form Autofill, defect, P3)

Description

[Alin Ilea, Desktop Test Engineering]

Attachment: 2024-06-25_16h45_15.mp4

Found in

• 129.0a1

Affected versions

• 129.0a1, 128.0a1

Tested platforms

• Affected platforms: Windows 10, Ubuntu 20, macOS 12

Preconditions

• browser.search.region = CA
• Have at least one Address already saved

Steps to reproduce

1. Reach the Address form on https://www.leons.ca
2. Click on any Address field and select an Address entry from the dropdown
3. Click on any autofilled field

Expected result

• The Clear Form dropdown should be displayed for all the autofilled fields.

Actual result

• The Clear Form dropdown is not displayed after the address form is autofilled.

Regression range

• Regressed by bug 1849122.

Aditional Notes

• Fathom Fox Sample

Comment 1

[BugBot [:suhaib / :marco/ :calixte]]

Set release status flags based on info from the regressing bug 1849122

:enndeakin, since you are the author of the regressor, bug 1849122, could you take a look?

For more information, please visit BugBot documentation.

Comment 2

[Neil Deakin]

This bug involves modifying the fix from 1849122 so as to only apply the change when a user modifies the form field, not a script change. Many sites are modifying the field state immediately after a value has been autofilled, typically to format the value such as add spaces between parts of a credit card number, and losing the yellow highlight.

Comment 3

[Neil Deakin]

Attachment: Bug 1904593, don't clear the autofill state when modified by script, r=#dom-core

It turns out that many sites are modifying the field state immediately after a value has been autofilled, typically to format the value such as add spaces between parts of a credit card number

Comment 4

[Dimi Lee [:dimi]]

Hi Neil, could you share more details about why the website has to modify the value after we autofill? Do websites only modify the value when what we autofill doesn't meet the requirement? I'm asking because if that is the case, we might also consider fixing the issue by filling the value that meet the requirement (if possible).

For the current solution, I'm not sure whether there will legitimate cases that website set the value by script because of user interaction. For example, a clear or reset button provided by the website. That's why i'm thinking the possible alternative solutions.

Comment 5

[Neil Deakin]

I've seen a number of cases:

• setting the value to the same value the field already has. I expected HTMLInputElement::OnValueChanged to not be called in that case but that is not the case.
• formatting the credit card to have spaces every four digits
• formatting the phone number to remove the initial '+' or add parentheses/spaces (leons.ca does this)

I'm assuming other formatting could occur such as formatting the postal code, modifying the state to be spelled out, etc.

I'm don't think we can guess what format the site expects, but I suppose one possibility is to compare the old and new values and only adjust the autofill state if the values has been changed to something that isn't equivalent even when not exactly equal.

But this issue currently affects a large number of Brazil/Swiss sites I've tested this week, and reverting part of 1849122 so that is doesn't reset the preview state when a script change is made will fix these.

Comment 6

[Dimi Lee [:dimi]]

(In reply to Neil Deakin from comment #5)

• formatting the credit card to have spaces every four digits
• formatting the phone number to remove the initial '+' or add parentheses/spaces (leons.ca does this)

Do you know whether Chrome clears preview for the above two cases?

I'm don't think we can guess what format the site expects,

We do have heuristics that guess what format the site expects, which is handled in this function. But of course, there will definitely be cases that we are not able to guess.

but I suppose one possibility is to compare the old and new values and only adjust the autofill state if the values has been changed to something that isn't equivalent even when not exactly equal.

Yes, i'm also thinking about the same solution. I think at least we should make sure setting the same value doesn't clear the state.

But this issue currently affects a large number of Brazil/Swiss sites I've tested this week, and reverting part of 1849122 so that is doesn't reset the preview state when a script change is made will fix these.

Right, but i worry that "doesn't reset the preview state when a script change is made" may introduce new issues. Also, i think we should make it clear to the users that as long as the value if different from what we autofill, then there is no highlight.

Comment 7

[Neil Deakin]

(In reply to Dimi Lee [:dimi] from comment #6)

Do you know whether Chrome clears preview for the above two cases?

On leons.ca, Chrome seems to not show the preview for the phone number. It does fill the phone number in correctly when an address is selected. It does not mark the phone field as filled in however.

Right, but i worry that "doesn't reset the preview state when a script change is made" may introduce new issues. Also, i think we should make it clear to the users that as long as the value if different from what we autofill, then there is no highlight.

Well I am just reverting the behaviour to what we had before bug 1849122 so I don't think it will be an issue. I can try to get this to handle the case when the value is unchanged however.

Comment 8

[Dimi Lee [:dimi]]

(In reply to Neil Deakin from comment #7)

Well I am just reverting the behaviour to what we had before bug 1849122 so I don't think it will be an issue. I can try to get this to handle the case when the value is unchanged however.

I see, thank you for the information.I was not aware that this was our behavior before Bug 1849122. You're right; we previously listened to the "input" event. Then yes, I think we can revert to the previous behavior with this patch. We should also file a bug to track the idea of updating the autofill state when the value is changed by a script and the value is really changed.

Comment 9

[Neil Deakin]

We should also file a bug to track the idea of updating the autofill state when the value is changed by a script and the value is really changed.

We can use the existing bug 1524439 for this I think.

Comment 10

[BugBot [:suhaib / :marco/ :calixte]]

Set release status flags based on info from the regressing bug 1849122

Comment 11

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/d0421393310a
don't clear the autofill state when modified by script, r=dom-core,credential-management-reviewers,dimi,sefeng

Comment 12

[Iulian Moraru]

https://hg.mozilla.org/mozilla-central/rev/d0421393310a

Comment 13

[Donal Meehan [:dmeehan]]

Neil, does this need a beta and esr128 uplift request?

Comment 14

[Alin Ilea, Desktop Test Engineering]

Verified - Fixed in Nightly 130.0a1 (2024-07-25), the clear form dropdown is displayed and the form is cleared accordingly.

Comment 15

[Neil Deakin]

Comment on attachment 9409960 [details]
Bug 1904593, don't clear the autofill state when modified by script, r=#dom-core

Beta/Release Uplift Approval Request

• User impact if declined: Regression issue that can affect some sites where the autofilled addresses cannot be cleared again.
• Is this code covered by automated tests?: Yes
• Has the fix been verified in Nightly?: Yes
• Needs manual test from QE?: No
• If yes, steps to reproduce:
• List of other uplifts needed: None
• Risk to taking this patch: Low
• Why is the change risky/not risky? (and alternatives if risky): Reverts part of the patch in 1849122 to go back to the previous behaviour when a script modifies a form but still allows user changes to reset the autofill state.
• String changes made/needed: None
• Is Android affected?: Unknown

Comment 16

[Donal Meehan [:dmeehan]]

Comment on attachment 9409960 [details]
Bug 1904593, don't clear the autofill state when modified by script, r=#dom-core

Approved for 129.0b9

Comment 17

[Pulsebot]

https://hg.mozilla.org/releases/mozilla-beta/rev/482cd6e6a7bd

Comment 18

[Donal Meehan [:dmeehan]]

Comment on attachment 9409960 [details]
Bug 1904593, don't clear the autofill state when modified by script, r=#dom-core

Approved for 128.1esr

Comment 19

[Pulsebot]

https://hg.mozilla.org/releases/mozilla-esr128/rev/a8603822753b

Comment 20

[Alin Ilea, Desktop Test Engineering]

Verified - Fixed in Beta 129.0b9 and 128.1.0esr. The clear form dropdown is displayed and the form is cleared accordingly.