Description:

Fixes #19509

Original problem: some plugins need to prevent an input from changing, like Funnels which needs to prevent a checkbox from changing until the user deals w/ a modal, but Vue will not notice when a model value doesn't change, and won't reset the input value in the case the parent component doesn't update the model value.

Fixes that didn't work:

• resetting the input value before emitting update:modelValue. This reset the input state to what the modelValue was in case the parent didn't update the modelValue, but changing the input's value reset the text cursor position which makes editing the middle of an input/textarea very annoying.
• resetting the input after emitting update:modelValue. This ends up always resetting the value because there's no way to know when the emitted event is done being handled, causing a consistent flash/backspace when typing.

This solution (only other one I could come up with):

This PR adds an 'abortable' model modifier that can be used to specify a Field can have it's change aborted. In this case, the event sent to update:modelValue has an abort() function that will reset the input value. This way the input value is only reset if the event handler aborts it, so the text cursor position never changes and there is no weird flash/backspace when typing. It can't really be used like a normal model modifier (ie, v-model.abortable) since it changes the event value, but this functionality is used very rarely in Matomo so I don't think that's much of an issue.

Usage is like:

<Field :uicontrol="text" :model-value="value" :model-modifiers="{abortable:true}" @update:model-value="doUpdate($event)"/>

doUpdate(event: AbortableEvent<string>) {
    if (...) {
        event.abort();
        return;
    }

    this.value = event.value;
}

Review

• Functional review done
• Potential edge cases thought about (behavior of the code with strange input, with strange internal state or possible interactions with other Matomo subsystems)
• Usability review done (is anything maybe unclear or think about anything that would cause people to reach out to support)
• Security review done
• Wording review done
• Code review done
• Tests were added if useful/possible
• Reviewed for breaking changes
• Developer changelog updated if needed
• Documentation added if needed
• Existing documentation updated if needed