whatwg
Resetting forms on document reactivation
The HTML Spec says for reactivation that fields with autocomplete=off should be reset.
This is the only instance in the spec of a reset being triggered like this. All other sources of resets are from calls to reset() in JS or from reset buttons. Authors of pages that have no reset button might be surprised that resets can still occur. and only listen for change events Such a page could have its JS state get out of sync with the form state, making this a potential source of hard to repro bugs.
It also seems that Chrome and Mozilla do not implement the spec but Safari does.
I don't have a great suggestion for what to do instead, just
You can test the behaviour of browsers with https://textarea-autocomplete-bug.glitch.me/
@mfreed7 @domenic @rakina
Related chromium bug: https://crbug.com/1418756
I understand the issues you raise about page authors getting caught off guard, or having a hard time dealing with this behavior. However, from the user's perspective, it feels odd to have the behavior change depending on whether the page is bf-cached or not. I.e. sometimes you hit "back" and your fields are clear, and sometimes they still contain the old input.
Does the pageshow event provide the appropriate mechanism for authors to handle this?
I think you're right, it will be surprising. So there may not be anything good action to take here. Perhaps just warning authors "hey you have an onchange but no onreset for this autocomplete=off field" so that they are aware of the gotcha is the best we can do.
It would be very confusing for the page to get reset when coming out of bfcache. Has webkit gotten bug reports about its behavior?
@smaug---- wrote
It would be very confusing for the page to get reset when coming out of bfcache.
Confusing for who? A user has pressed back, they don't know about BFCache, not resetting autocomplete=no fields is confusing for users. Resetting them is probably unanticipated by devs.
One thing we discussed in the call is that this should be consistent between a session history entry having a pointer to a document and it not having a pointer to a document. In particular in the latter case user agents perform form restoration and it should not be the case that we only reset there.
Another point that was brought up is that we should revisit whether autocomplete=no is really in the interests of end users.
I've also done some quick archeology:
- https://github.com/whatwg/html/commit/4a2bc22484a615bf318ed7e549c6fd0ba0764cda clarified that form restoration does not fire events, but does call
formStateRestoreCallback(). Perhaps something similar is needed here? (Though maybe not until https://github.com/whatwg/html/issues/9065.) - https://github.com/whatwg/html/issues/7292 discusses further Interop on form restoration and also suggests web developers already need to look at
pageshowif they want to be aware of what happened to their form controls. That suggests no change is needed here (except for considering ignoringautocomplete=offcompletely).
Another point that was brought up is that we should revisit whether
autocomplete=nois really in the interests of end users.
I'm ok considering whether autocomplete should control form restoration, but if the answer is "no", then there definitely needs to be a replacement attribute that can control form restoration. E.g. formstaterestoration=off or something. This is a real use case, in production on several big sites.
This is a real use case
What is the use case?
An input element that is always cleared when the user returns to the page. At least one site doing this is www.google.com.
The spec says for autocomplete=off:
The "off" keyword indicates either that the control's input data is particularly sensitive (for example the activation code for a nuclear weapon); or that it is a value that will never be reused (for example a one-time-key for a bank login) and the user will therefore have to explicitly enter the data each time, instead of being able to rely on the UA to prefill the value for them; or that the document provides its own autocomplete mechanism and does not want the user agent to provide autocompletion values.
https://html.spec.whatwg.org/multipage/form-control-infrastructure.html#attr-fe-autocomplete-off
The main intent is to avoid prefilling by the UA, not preventing restore on history navigation.
Assessing whether not restoring on navigation makes sense for the stated use cases:
- the control's input data is particularly sensitive: yes
- a value that will never be reused: yes
- the document provides its own autocomplete mechanism: not necessarily
google.com falls into the third category, but wants to clear the value on history navigation. However, for pages in general, I think it doesn't makes sense to clear the value on history navigation just because the page implemented custom autocomplete.
I ran a query in httparchive to find examples of how autocomplete="off" is used (on form, input, textarea, select), for pages with rank magnitude <= 10,000.
https://docs.google.com/spreadsheets/d/1zE62w1lFEi-hD2e5wQEuYDi69JNukn8LYu4pUr_6lZE/edit?usp=sharing
Of these, there are 257 pages with an aria-autocomplete attribute, indicating that these are likely in the third category (but pages without such an attribute might also be):
https://docs.google.com/spreadsheets/d/1GSKnciAyWObxFUSrtLvrTicGZCJbWyd1tw5xNQX2-VE/edit?usp=sharing
I haven't yet looked at these in detail.
google.com falls into the third category, but wants to clear the value on history navigation. However, for pages in general, I think it doesn't makes sense to clear the value on history navigation just because the page implemented custom autocomplete.
Even google.com doesn't clear the value on history navigation when navigating between google.com/search pages, only when going back to the home page. (To reproduce, search for something in google.com, then on the results page, edit the search to something else, press enter, then go back in history.) In both cases autocomplete=off is used.
This suggests that either restoring is OK and sites can clear manually in the pageshow event, or we can add a declarative way to clear fields on history navigation. To make the non-bfcache case consistent, form data should be stored in https://html.spec.whatwg.org/#she-other even for autocomplete=off fields.
It also seems that Chrome and Mozilla do not implement the spec but Safari does.
All 3 browsers do not implement the spec for textarea -- Safari only clears the input in https://textarea-autocomplete-bug.glitch.me/ as far as I can tell. (google.com uses textarea.)
Thanks for the detailed analysis! It feels like we shouldn't require JS to implement this behavior, since an attribute feels the most natural. It's quite frustrating to developers to need to do tricks to get browsers to do what they want, such as autocomplete=nope. If we don't want autocomplete to be the knob used to control form restoration, then we should provide another (attribute) knob, in my opinion.
Quick side note about textarea - I changed Chromium to not restore <textarea autocomplete=off> in February.
A new attribute to control restoration SGTM, with the default being to restore (regardless of autocomplete or bfcache/non-bfcache).
As a FACE (form-associated custom element) library author, I would assume autocomplete has nothing to do with form restoration. Let's say I have a form of 10 fields. Some are check boxes, some are select. Some are custom autocomplete.
The first of the controls is a custom autocomplete with autocomplete=off. Let's say it's an address field that uses a GIS service for accuracy. As user is scrolling through a page, that form control has left the viewport. After the 5th control, the user finds a note for a form control with a (More Info) button. Not knowing the link will redirect them (perhaps expecting a toggletip/dialog), they click it. They are sent offsite. They hit back. They see some of their form fields have been retained. They hit submit at the end of the form.
In my opinion, it would be reasonable for a user to assume because controls in their viewport were restored, all the fields were restored. It's not reasonable to think the user needs to verify the entire page because some elements follow special rules hidden to the user.
As the author, should I code special handling? Should I need to do some special detection that a form getting restored may have a field with autocomplete off and of a specific type and instead abort the entire form restoration in order to maintain consistency?
