(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](https://searchfox.org/mozilla-central/rev/b368ed8b48c0ea8ed2f1948e4776a6fbb5976dff/toolkit/components/formautofill/shared/FormAutofillSection.sys.mjs#96). 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 if the value if different from what we autofill, then there should be no preview highlight.
Bug 1904593 Comment 6 Edit History
Note: The actual edited comment in the bug view page will always show the original commenter’s name and original timestamp.
(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](https://searchfox.org/mozilla-central/rev/b368ed8b48c0ea8ed2f1948e4776a6fbb5976dff/toolkit/components/formautofill/shared/FormAutofillSection.sys.mjs#96). 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 if the value if different from what we autofill, then there is no highlight.
(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](https://searchfox.org/mozilla-central/rev/b368ed8b48c0ea8ed2f1948e4776a6fbb5976dff/toolkit/components/formautofill/shared/FormAutofillSection.sys.mjs#96). 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.