Resetting forms on document reactivation

[fergald]

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

[mfreed7]

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?

[fergald]

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.

[smaug----]

It would be very confusing for the page to get reset when coming out of bfcache. Has webkit gotten bug reports about its behavior?

[annevk]

I'm not aware of any, but we'd be okay with removing this functionality.

[zcorpan]

cc @whatwg/forms

[fergald]

@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.

[annevk]

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:

• 4a2bc22 clarified that form restoration does not fire events, but does call formStateRestoreCallback(). Perhaps something similar is needed here? (Though maybe not until New attribute to control UA-provided writing assistance #9065.)
• Form restoration interop #7292 discusses further Interop on form restoration and also suggests web developers already need to look at pageshow if they want to be aware of what happened to their form controls. That suggests no change is needed here (except for considering ignoring autocomplete=off completely).

[mfreed7]

Another point that was brought up is that we should revisit whether autocomplete=no is 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.

[annevk]

This is a real use case

What is the use case?

[mfreed7]

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.