Reset algorithm doesn't work in form-associated custom elements

[dSalieri]

What is the issue with the HTML Standard?

There are 3 places in the specification where the reset algorithm is triggered:

1. The reset algorithm, which resets the state of all form participants to default values

   2. If reset is true, then invoke the reset algorithm of each resettable element whose form owner is form.

2. The create an element for a token algorithm, whose task is to create an element for the HTML parser.

   13. If element is a resettable element, invoke its reset algorithm. (This initializes the element's value and checkedness based on the element's attributes.)

3. The reactivate algorithm, which is used to update the document

   1. For each formControl of form controls in document with an autofill field name of "off", invoke the reset algorithm for formControl.

The first case works fine, no questions about it, no matter whether via a button or via the reset() API, it works well and the formResetCallback hook makes itself known.

The second case fails, it does not call the formResetCallback hook (detailed below).

The third case also does not execute the formResetCallback hook, the conditions for its execution are unachievable (due with form-associated custom elements).

---

As a small test, I made this example for the create an element for a token case:

<script>
customElements.define("my-input", class extends HTMLElement {
  static formAssociated = true;
  connectedCallback() {
     console.log("my-input connected");
  }
  formResetCallback() {
     console.log("my-input performed formResetCallback");
  }
});
</script>
<form>
  <my-input></my-input>
</form>

And if you run such html file with a custom element that has the reset algorithm:

The reset algorithm for form-associated custom elements is to enqueue a custom element callback reaction with the element, callback name "formResetCallback", and an empty argument list.

Then we will not see the called formResetCallback hook, but this should work (yes, we are talking about the second case, when the HTML parser creates an element for the token and after run reset algorithm in step 13).

I checked this in the latest Chrome and Firefox, the hook is not called. What's wrong?

---

Maybe problem is in this note, why implementations don't correspond the step 13:

A custom element possesses the ability to respond to certain occurrences by running author code:

• When the form owner of a form-associated custom element is reset, its formResetCallback is called.

By the way, that wpt test is too old, it does not check what I am talking about.

---

What do you say editors?

[domfarolino]

Thanks for the investigation! I agree this is strange; I can't get the formResetCallback in your example to run in any browser despite the spec which seems to call for its invocation during construction. I'm wondering if this is really just a bug in all implementations or if there is a subtle part of the spec that excludes the callback from being run in this case. @mfreed7, any chance you know?

[mfreed7]

I'm wondering if this is really just a bug in all implementations or if there is a subtle part of the spec that excludes the callback from being run in this case. @mfreed7, any chance you know?

Interesting - I can confirm. That does sound like a correct reading of the spec, but it doesn't seem to be implemented. Unfortunately, I don't know the history here, so I don't know if that's a spec accident or a browser accident. I'm also wondering if it would be web compatible to just start calling formResetCallback every time we parse a FACE? Feels like potentially no?

[dSalieri]

There is a suspicion why implementations do not do this.

If you look at the upgrade an element algorithm, you will see that step 9 enqueues some reactions related to the form-associated custom element:

9. If element is a form-associated custom element, then:

   1. Reset the form owner of element. If element is associated with a form element, then enqueue a custom element callback reaction with element, callback name "formAssociatedCallback", and « the associated form ».

   2. If element is disabled, then enqueue a custom element callback reaction with element, callback name "formDisabledCallback" and « true ».

But note there is no reaction related to the formResetCallback.

Therefore, I guess that for consistency with upgrade an element, the reaction with formResetCallback is also not enqueue in the create an element for a token algorithm in the step 13:

13. If element is a resettable element, invoke its reset algorithm. (This initializes the element's value and checkedness based on the element's attributes.)

As I think, it seems to me that either formResetCallback should be added to the upgrade an element algorithm or modified in the create an element for a token in the step 13, where it will be indicated that reset algorithm is not called for the form-associated custom element.

Opinion? @domfarolino @mfreed7