Exiting a @change handler undoes changes made in the handler

[ssilverman]

Observed (with Javascript tracing in Safari on a Mac):

1. Change a text input value to something I know is invalid (in my case, it's one character too long, specified with both a pattern attribute and checked in a "check()" function)
2. @change event gets fired
3. The event handler first sets the border colour to empty (e.target.style.borderColor = "")
4. Then a check() function is called (still inside the change event handler)
5. The function correctly identifies that there's a problem with the text and sets the element's style.borderColor to "red"
6. I observe this change while stepping through the code — the border turns red
7. The function exits — the border stays red, as desired
8. Tracing goes to the element itself, and when I hit "step over", the input element goes back to having no border colour

I run through these steps again, and instead of "step over", I hit "step into" and trace the "undo my changes line" (in an un-minified arrow.js, (Source: https://cdn.skypack.dev/pin/@arrow-js/core@v1.0.0-alpha.10-0OtiX3AAm50MbkUEpziB/mode=imports/optimized/@arrow-js/core.js)):

function setNode(value, p) {
  const isUpdate = typeof p === "function";
  const partial = isUpdate ? p : createPartial();
  Array.isArray(value) ? value.forEach((item) => measure("partialAdd", () => partial.add(item))) : partial.add(value);
  if (isUpdate)
    partial._up();  // <-- HERE

The code is getting a little complex for me, but I know that when that partial._up(); line is processed, the element has all my changes reverted.

Note that I also tried setting the className property when there's an error to "has-error" (accompanied by an input.has-error { border-color: red } style in a <style> section), and also tried adding to classList, but all three approaches (setting style.borderColor, setting className, and doing classList.add("has-error")) lead to the border colour being changed to red, followed by reverting to non-red when the change handler exits.

I tried making a small representative example, but that example doesn't fail, so it could either be my logic, or the error only happens when there's a much larger DOM tree. If you like, I'm happy to screen share and prove that exiting a change handler undoes my changes when inside the ArrowJS code.

Thanks again for a wonderful library! It's helping me get started with modern web page design.

[ssilverman]

As I trace through this, I notice that before losing the changes to the element, and as I trace through multiple partial._up() calls (because it loops over some table rows), the element changes are transferred to a different element (i.e. the second row's text and border become the first row's text and border colour), before being removed again.

So I see, as I trace:

1. My now-red input element's contents and colour are transferred to a different element, keeping the first element's changes
2. Now I have two input elements that look the same
3. The first element's contents are reverted by the ArrowJS code to non-red, and then the second element gets restored to its original state.

[ssilverman]

Some more clues: If I use an @input handler instead of a @change handler, the input element loses focus whenever I type a character. This also seems like odd behaviour.