Inform user if value was changed automatically

[Helium314]

Description

The width field (and maybe some others) may adjust the entered value if it's detected as a number, e.g. .4 is changed to 0.4, 08 is changed to 8.
When the value starts with a digit, it is automatically truncated to a number, e.g. 3a is changed to 3.

I believe this automatic truncation may lead to wrong (2 instead of 2,8) or even invalid (0 instead of 0,5) data.
I think it is important to inform the user that the actual stored value is not what was entered, as this is rather unexpected behavior, especially because similar numeric fields like maxwidth, maxweight or maxheight don't do this.

Related issue: #3615 would help in a common case of a wrong decimal separator leading to truncating that value.

Screenshots

No response

[1ec5]

When the value starts with a digit, it is automatically truncated to a number, e.g. 3a is changed to 3.

The Width field currently expects a numeric value, so the “a” would be unexpected anyways. ideditor/schema-builder#15 would change this field to a new measurement type, but ideally iD would present a dropdown menu for selecting the unit instead of making you type it out manually.

Besides those measurement fields and the numeric fields that would be addressed by #8769, are there any other situations where the automatic number parsing would cause problems? Fixing those problems in the first place would be better than presenting a warning each time it happens.

[Helium314]

The Width field currently expects a numeric value

Then simply complain to the user when a non-numeric value is entered. This would also stop users from entering purely non-numeric values (which are not changed at all).

Fixing those problems in the first place would be better than presenting a warning each time it happens.

I would be, but I expect the user will not try to enter 3a over and over if there is a warning every time.
Plus, the problem has been known for ~6 years now and was not fixed, leading to many invalid (0 instead of 0,5) or hard to detect incorrect (2 instead of 2.5) values. So at least the user should be warned if the input is considered invalid until the problem is fixed.

[1ec5]

Then simply complain to the user when a non-numeric value is entered. This would also stop users from entering purely non-numeric values (which are not changed at all).

There is some minimal value validation for some fields such as Email. The validation you’re proposing would be implemented similarly. However, it should only be applied to fields whose values must be numeric, not fields whose values are usually numeric but can sometimes be non-numeric, for example Direction.

Plus, the problem has been known for ~6 years now and was not fixed

#8769 is waiting to get merged, so fixing the root cause is even easier than implementing the proposed workaround.