CustomField calling setPresentationValue even though trigger came from client-side

Using version 1.1.2.

I have a widget that is a subclass of CustomField and wraps a TextField. (Specifically, it edits an Integer with significant digits and rounding, but this is not relevant to the problem.)

My implementation handles events manually by implementing TextField.addValueChangeListener on the wrapped TextField. It does not listen to changes on the CustomField.

The problem is that the browserless-test framework is calling CustomField.setPresentationValue in response to changes from the user. The sequence is:

1. Test code simulates the user inputting a value by calling ComponentTester.setValueAsUser(value) on the CustomField.

2. This calls CustomField.getFieldSupport().setValue(value, false, true);

3. Because fromInternal=false, this calls AbstractFieldSupport.applyValue(value);

4. That calls setPresentationValue.accept(value) on the CustomField.

The documentation at https://vaadin.com/docs/latest/components/custom-field reads:

Custom Field triggers [setPresentationValue] to update child component values when its value changes programmatically on the server-side.

But it DIDN'T come from the server-side; it came from the client. In step2, fromClient=true.

5. My implementation of CustomField.setPresentationValue assumes the change is coming from the server. It updates the TextField. This triggers a TextField event which the CustomField ignores because it is server-side. (This step is not relevant to the problem; I am just explaining it for completeness.)

6. The AbstractFieldSupport.setValue method fires an event for the CustomField with the correct value of fromClient=true. However, I am not listening to it.

I suppose I could fix this one case by listening to the CustomField instead of the TextField. However, I have many other cases where the CustomField contains more than just a TextField: Code that listens to each widget individually is cleaner and easier to follow.

Another option is to alter my custom ComponentTester to set the value on the TextField rather than the CustomField. I plan to try this next.

My concern is that my code has to handle an unnecessary setPresentationValue. Is this a "real issue" or is it a "false artifact"? Meaning, specifically, will the actual browser ever update the value directly on the CustomField, which is what I am simulating?

A. If the browser never updates the value directly on the CustomField, this is a non-issue.

B. If the browser updates the value directly on the TextField, my listener will work correctly. And the correct implementation of my ComponentTester is to update the TextField and not the CustomField.

Prior to further testing, I suspect "A" is the answer, because I have parallel testing in place with playwright, where it does work correctly.

Start with ComponentTester.setValueAsUser(value), CustomField.getFieldSupport().setValue, AbstractFieldSupport.setValue, and the setPresentationValue call described in the report. Compare this path with how an actual browser updates the wrapped TextField, then determine whether the tester should target the child component or whether CustomField should avoid the call for client-originated changes. Done means the browser and browserless-test behavior are consistent.