Should input/change events be fired when the UA restores a form?

[mfreed7]

The existing spec seems to say that input and change events should be fired whenever the UA performs form filling/restoration activities:

When the user agent is to change an input element's value on behalf of the user (e.g. as part of a form prefilling feature), the user agent must queue an element task on the user interaction task source given the input element to first update the value accordingly, then fire an event named input at the input element, with the bubbles and composed attributes initialized to true, then fire an event named change at the input element, with the bubbles attribute initialized to true.

Chromium recently fixed a bug here and implemented this behavior, which landed in M90. We have received only one bug report about the new behavior, so I think it is relatively safe to assume this change was web compatible.

Gecko and WebKit do not currently appear to implement the above event firing behavior.

It would seem to me that we should honor this part of the spec - from a developer's point of view, the value of the input is being changed (on the user's behalf by the UA), so events should be fired to allow the developer to know about that. I've seen many site bugs caused by UA-filled inputs not being "noticed" by the site. E.g. by password fillers. But thoughts appreciated.

[annevk]

This seems reasonable to me. It would be great if we had some autofill infrastructure in web-platform-tests.

cc @whatwg/forms

[tkent-google]

I have seen real sites in which 'change' event handlers trigger navigation. We might need to disallow navigation while UA is restoring values.

e.g.

<input type=file onchange="this.form.submit()">

<select onchange="location.href = this.value"><option value=foo.html>foo</option>...

It seems the Chrome change changed the behavior for some input types, excluding <input type=file> and <select>.

[domenic]

Not restoring file inputs seems reasonable to me. But select seems like it should be restored, if we can get away with it...

[domenic]

However upon a moment's further consideration I think there's just no way restoring select would be web-compatible without some mitigation of the type @tkent-google discusses. Those kind of dropdown-to-navigate patterns are too prevalent. Hmm.

[mfreed7]

So this seems like people generally agree with the existing spec language. I'm thinking I should just file browser bugs. Does that make sense to people?

[domenic]

I think we're scared that the existing spec language might not be web-compatible for select and file inputs.

[kohler]

As a web developer, I'm currently having difficulty adapting to Chrome's new change event behavior, and would like to advocate disallowing Chrome's new behavior. That is, input/change events should not be fired when the UA restores a form.

The current spec language speaks of change and input events as being generated by the user. It explicitly says they are not generated by scripts. Restoring a form after navigation is arguably more like running a script than like the user typing stuff into inputs.

Example problem: Web forms commonly trigger back-end actions on change events. Clicking a box or entering text in an input might automatically submit an XHR to a remote server. After Chrome's update, navigating back to a form can cause a cascade of XHRs as the user’s changes are all re-applied. These redundant XHRs may take a while to crop up as problems or to be fully diagnosed. But they are problematic—for instance, a redundant XHR might overwrite a change that was made by another user.

[mfreed7]

Thanks for adding the comment here. Also thanks for the comment you just made on the Chromium bug. I actually wanted to copy part of that response here, because it has a nuance that is interesting to me.

So the spec currently says this:

When the user agent is to change an input element's value on behalf of the user (e.g. as part of a form prefilling feature), the user agent must queue an element task on the user interaction task source given the input element to first update the value accordingly, then fire an event named input at the input element, with the bubbles and composed attributes initialized to true, then fire an event named change at the input element, with the bubbles attribute initialized to true.

And you said:

That's one read. You could also emphasize “changes”. In form pre-filling, from the user's point of view, the control changes on their behalf, and a change event seems appropriate. In navigation, the control preserves its prior state: the relevant change event has already fired. The spec is clear that change events are fired when the control changes value. In navigation, the control is not changing value from the user's POV (it is just changing because of how navigation is implemented in this browser). And when interpreting the spec, shouldn't one put weight on currently implemented behavior, which was the same for all three browsers for many years before April?

The point you make is that from the user's point of view, nothing is changing, they're just "going back" to the past page, with form values (and everything else!) intact. I can certainly see that. And in fact that made me revisit the original bug that triggered my change to Chromium. In that case, there are some other elements on the page that "respond" to changes in the inputs. And the bug was that those other elements don't get properly "restored" when a tab is duplicated or a back/forward navigation happens. But the interesting thing there is that that behavior (not restoring the other elements) is a Chromium-only behavior. Gecko and WebKit both restore the entire page, so there's no need to re-fire the input/change events to re-synchronize.

I adapted this example page to show this. The text values next to the range sliders respond to input/change events and change accordingly, but with a 2 second delay so you can see them. In Chromium, before the delay, you can see the bug - the sliders are restored, but the text does not match. After the events fire, things look good again. But this behavior is not shared by Gecko and WebKit - they both restore the full page, including the modified values, immediately. They have no need, therefore, for the extra events being fired.

I'm beginning to think I should restore Chromium's behavior.

Regardless of that decision, clearly it would be good to at least clarify this part of the spec. We should define (or link to?) what it means to "change" an input element's value.

[mfreed7]

One of my action items from the last spec triage meeting was to experiment with the behavior of element restoration across engines. I put together this doc with the results:

https://docs.google.com/document/d/1DsqyuK5NeV_EYQ-2Sa3-OofjDDQL47VIiV6ev9fWvu4/edit?usp=sharing&resourcekey=0-sCyHpHpHlfG3V1XbM8veKA

Apologies for sharing as a Google Doc, but it was a lot easier to build the table. Please address comments back here to this thread, and not in the doc.

TL;DR: there are definitely some differences between the engines for non-form elements (e.g. <span>), file inputs (<input type=file>), and generally around what happens for Back/Forward, Duplicate Tab, and Refresh. My comment above still stands, I believe: I'm thinking Chromium should likely go back to not firing input/change for these navigations.