input fields fire change events on invalid input before change is committed

[maribethb]

Check for duplicates

• I have searched for similar issues before opening a new one.

Description

A text input field fires "intermediate field value change" events while the user is editing the input. When they press the "enter" key, their change is "committed" and we fire an actual BLOCK_CHANGE event with the old and new value.

However, if the value is rejected by a field validator, then a BLOCK_CHANGE event will be fired before the user commits their change. If a user does press enter while the text input contains an invalid value, then the value of the field will be reset to whatever it was before the user started typing at all.

In my opinion, this is a bug and not how these two events should behave. The goal of introducing the "intermediate" event was to allow developers to listen to events specifically that occur when the user commits or finalizes their change. Firing the final block change event before they commit the change seems wrong from that perspective. And really, firing the final block change event at all seems wrong, because if they do commit their change in that state, the value of the block doesn't change at all anyway, so the old and new value should match in theory.

Reproduction steps

1. Create a block with a field validator that will sometimes reject the input
2. Enable event logging
3. Edit the block such that the validator you created will reject the input, but do not press enter
4. Notice that the field is still being edited, the background is red, and you get a BLOCK_CHANGE event fired even though you are still typing into the block

Stack trace

This occurs because `doValueInvalid_` in `FieldInput` fires a `BLOCK_CHANGE` event.

Screenshots

No response

Browsers

No response