fix!: Only fire intermediate events when editing input with invalid text.

[johnnesky]

The basics

• I validated my changes

The details

Resolves

Fixes #7966

Proposed Changes

This propagates the fireChangeEvent parameter to the doValueInvalid_ method, and uses it to conditionally inhibit the default behavior of firing a block change event when a field is assigned an invalid value.

I also made a significant change to the way doValueInvalid_ reverts the field value. Previously, it copied the value from this.htmlInput_!.getAttribute('data-untyped-default-value'), which is always a string value. However, this doesn't really make sense for number fields, which usually contain a numerical value even when editing the associated text input widget. I replaced it with this.valueWhenEditorWasOpened_ which is the exact value the field used to have.

Finally, I conditionally skip firing the block change event if the new (reverted) value was the same as the value was before the most recent (invalid) edit.

The intermediate field change events were already being fired correctly (in addition to the incorrect block change events) so I didn't need to change that.

Reason for Changes

Test Coverage

I updated some existing unit tests to expect numerical values for numerical fields instead of string values when the validator returns null. I guess this is technically a breaking change.

Documentation

N/A

Additional Information

N/A

Breaking changes / To fix

This affects the data type assigned to a field's value when an invalid value is provided.

When a user selects a number field and types letters instead of numbers, the attempt to set the field's value to the user's input will fail, and instead the internal value of the field will be reset to what it used to be before the user started to edit it. However, the value assigned to the field in this case used to be a string containing numerals instead of the actual original number, whereas after this change the original number will be assigned instead.

[maribethb]

LGTM. Can you add a section to the PR description that makes it clear to readers of the release notes why this is a breaking change and what they might need to do in response. Here's an example in another PR #7991

[maribethb]

Also note that the angle tests may need to be updated in the rc/v11 branch of blockly-samples. They've already been deleted from the rc/v11 branch of core because the fields themselves were removed.

[johnnesky]

Thanks! I updated the description.

Actually I think the angle field tests in blockly-samples will be okay?