Open Bug 1020829 Opened 10 years ago Updated 2 years ago

[ux] Figure out the UX for when a user's autofill profile doesn't meet the requirements of the form

Categories

(Toolkit :: Form Autofill, defect, P3)

defect

Tracking

()

People

(Reporter: MattN, Unassigned)

References

(Blocks 1 open bug, )

Details

See bug 1020819 for some more background. When requestAutocomplete is called, the user can choose from their existing profiles. The form being autofilled can have various restrictions (most listed in bug 1020819) which may not align with the data in existing profiles. We need a UX design to be able to help our user as much as possible while still honouring the spec and requirements of the author. If we don't, the user may be stuck with a validation error after requestAutocomplete and that may not be a well-tested aspect of the website. There are many heuristics that we will employ to try and make data fit in certain cases but this design doesn't need to worry about that and should only focus on cases where the it's not possible to reconcile what the user's profile has and what the page wants. The behaviour could vary depending on the field that doesn't match. Some ideas of things we can do: A) At any point, we can decide that we aren't going to auto-fill the whole form and bail by sending the "disabled" event to the page. The page will likely get the user to manually fill the form instead. I'm not sure we would ever use that for this case though since we could get the user to create a new profile which also enforces the form's restrictions. B) Filter the list of saved profiles to only list ones that match all of the <form>'s requirements. The user always has an option of creating a new profile if none meet the requirements. The downside is that we need to communicate to the user why the other profiles are not available (maybe greyed-out and disabled with a message) and creating a new profile may mean re-typing data from an existing profile (with some small tweaks for the webpage) unless we implement a clone/copy profile ability. C) Let the user choose any of their profiles but show inputs below the field selection for any fields that don't match the page's requirements. Upon editing, give the user the option of either saving as a new profile or updating the existing (perhaps a checkbox?). Some examples: 1) The page only allows the country to be USA or Canada. The user may have zero or more profiles for these countries. They shouldn't be allow to choose an address from France. 2) A US website doesn't have a country field (since it only allows submissions for US customers) but a user doesn't realize this. The website has a postal-code field for the ZIP code which is <input maxlength=5 inputmode=numeric autocomplete="postal-code">. A Canadian profile with a postal code of H0H 0H0 shouldn't be able to auto-fill their profile into this form as-is since it's longer than 5 characters. We shouldn't transform (e.g. truncate) the postal-code to fit in this case since that would be wrong. 3) '…if a select element only has option elements with values "Steve" and "Rebecca", "Jay", and "Bob", and has an autofill field name "given-name", but the user agent's only idea for what to prefill the field with is "Evan", then the user agent cannot prefill the field. It would not be conforming to somehow set the select element to the value "Evan", since the user could not have done so themselves.' [1] Please refer to the list of possible validation issues in the spec or at least the quote in bug 1020819 when thinking about the design. [1] http://www.whatwg.org/specs/web-apps/current-work/#attr-fe-autocomplete
Flags: firefox-backlog+
requestAutocomplete was removed from the HTML specification but this still applies for Form Autofill
Component: Form Manager → Form Autofill
Whiteboard: p= → p= [ccautofill]
Priority: -- → P3
Whiteboard: p= [ccautofill]
Severity: normal → S3
You need to log in before you can comment on or make changes to this bug.