1032762 - Audit user-controllable preferences that affect the behavior of the requestAutocomplete method

Status: RESOLVED INVALID

(Toolkit :: Form Manager, defect)

Description

[:Paolo Amadini]

We currently have preferences to enable or disable the "autocomplete" attribute and the "requestAutocomplete" method at the DOM level.

Even if the feature is enabled at the DOM level, there should be a way for the user to control whether to store personal information and provide it to websites when asked. In case the feature has been blocked, the "disabled" event should be generated when the requestAutocomplete method is called.

Comment 1

[Evan Stade]

Note that for Chromium, we initially had a way for the user to disable requestAutocomplete, but we scrapped it in favor of allowing the user to globally disable storing details. The difference is that the UI should always show, which is important because merchants will be able to rely on the UI existing instead of having to create a fallback UI (at least in the utopia where all browsers implement rAc, or you somehow know all your users are on a certain browser). Even if Chrome is not storing or recalling user details, the native UI, input validation, etc. is still a win.

Comment 2

[:Paolo Amadini]

(In reply to Evan Stade from comment #1)
> Note that for Chromium, we initially had a way for the user to disable
> requestAutocomplete, but we scrapped it in favor of allowing the user to
> globally disable storing details. The difference is that the UI should
> always show, which is important because merchants will be able to rely on
> the UI existing instead of having to create a fallback UI (at least in the
> utopia where all browsers implement rAc, or you somehow know all your users
> are on a certain browser). Even if Chrome is not storing or recalling user
> details, the native UI, input validation, etc. is still a win.

That is a good point, in fact it highlights how deciding the exact way these options are available to the user is not particularly easy.

For example, I believe some websites may want a way to know whether the details will not be stored locally, to provide an alternate workflow where they offer the user the option to store the details on the server side for that site only.

Another factor is that the browser-provided user interface might be unavailable for other compatibility reasons, for example because different browsers support different sets of fields. At present, as expected since it is a work-in-progress, the specification is not particularly useful in predicting whether a given set of fields will work in all browsers. And it is quite possible that adding a new field will cause the entire UI to be unavailable in some browsers.

This is just to say that we're quite far from that utopia you mentioned, so we may follow a similar route and allow UI to be disabled at first, and change the available options when we're confident we can send the message that the UI will work consistently in modern browsers, and websites may reasonably avoid to provide an alternate input method.

Comment 3

[Evan Stade]

(In reply to :Paolo Amadini from comment #2)
> For example, I believe some websites may want a way to know whether the
> details will not be stored locally, to provide an alternate workflow where
> they offer the user the option to store the details on the server side for
> that site only.

Maybe, but if the user has already said "no, don't remember this info" once, they'd probably not like to be asked again.

> This is just to say that we're quite far from that utopia you mentioned, so
> we may follow a similar route and allow UI to be disabled at first, and
> change the available options when we're confident we can send the message
> that the UI will work consistently in modern browsers, and websites may
> reasonably avoid to provide an alternate input method.

The utopia is not necessarily all or nothing --- a site author might implement a fallback UI but not put very much effort into it, relying on a large portion of their users getting the polished and perfected browser-native UI. I can see the use case for disabling storing of details, but what is the advantage (security? privacy? other?) of letting some users disable the input/validation UI?

Comment 4

[:Paolo Amadini]

(In reply to Evan Stade from comment #3)
> The utopia is not necessarily all or nothing --- a site author might
> implement a fallback UI but not put very much effort into it, relying on a
> large portion of their users getting the polished and perfected
> browser-native UI.

Yes, I can see that we'll be there at some point, but it is too early to know when.

> I can see the use case for disabling storing of details,
> but what is the advantage (security? privacy? other?) of letting some users
> disable the input/validation UI?

Maybe none, if we can handle the data storage preferences correctly. Since this is a web-facing feature, however, we should carefully evaluate our options before making a decision.

For the moment, I agree that we don't need to implement another global preference until we are disabled by the "about:config" setting. We'll probably want to check where we are with regard to user control before we activate the feature.

Comment 5

[Matthew N. [:MattN]]

requestAutocomplete was removed from the HTML specification.