Numberinput cannot input .0 after any number.

[aiueo13]

On mac, in Numberinput, we cannot input .0 after any number.
Inputting 1.0 immediately forces it to 1
But Android can it. Other is unknown.

[metonym]

Can you provide sample code?

[brunnerh]

Example

It's does not appear to be an operating system issue. Chrome & Firefox do not have this issue on MacOS.

Safari 17 (macOS Sonoma) does truncate.
Safari 16 (macOS Ventura) does truncate.
Safari 15 (macOS Monterey) does not truncate.

Behavior is different from plain number input which does not seem to ever truncate.

There also appears to be an issue that pressing backspace can delete decimal places and . and move the cursor, so it goes from:

1.1|

to

|1

• It does not happen if the deletion results in the same number, just written differently.
  So going from 1 to 1.0 and hitting backspace only removes the 0 leaving 1..
• Cursor does not jump to the front in all major browsers, maybe only in Chrome.
• In Safari 17 & 16 deletion of the . does not happen, instead the value becomes null while the input ends in ..
  In Safari 15 is does happen.

There probably needs to be some logic to prevent the input value from being forcibly updated.

[metonym]

I wonder if explicitly setting a step value would solve this.

<NumberInput value={1} step={0.1} label="Clusters" />

[brunnerh]

It does not; already suspected and tried that. (Plain number input does not need it either.)

[jorgebv]

I don't have all of the different OS's to try on, but binding to the input value instead of setting it inside the on:input event handler seems to help with some of the issues identified by brunnerh; in particular I was experimenting for a remedy to the cursor jumping in Chromium browsers.

I just lack the ability to test on Mac/Safari which the comment thread started with, so I'm hesitant to make a PR.

I see the binding of the value was also attempted in another open PR #1584 (comment), but I think the binding alone could be done as a non-breaking change.

[kennethklee]

This issue affects Firefox, Safari, Chrome, Chromium on desktop and mobile. When pressing backspace once for value, 1.1, the cursor moves to the front and it removes extra . at the end so 1.1 will result in 1 instead of 1.. On firefox (desktop and mobile), only the . at the end gets removed. Cursor seems to stay at the end.

Based on code, it appears to be parsing for number on every input. This could be causing this unusual issue.

carbon-components-svelte/src/NumberInput/NumberInput.svelte

Lines 140 to 142 in 44a2989

	function parse(raw) {
	return raw != "" ? Number(raw) : null;
	}

Perhaps the parsing is done to ensure value is always a number or blank? Since <input type=number> is supported across the board and already ensures the resultant value is number or blank, the parsing could be removed.

I'd make a PR, but I don't understand the full implications of removing the parse().

[brunnerh]

Parsing exists so the value property and event data can be a number rather than a string.

[divinedesign-se]

We had issues with this and similar behaviour in different browsers in our project. For us it was mostly the issue that backspace with the cursor at the end on 1.4 or similar moves the cursor to start instead.

For example: Try changing value 2.8 to 2.1:

• Put the gain value 2.8. By typing or by buttons.
• Place the cursor behind "8", press Backspace key to delete "8". Now we want to type "1", but...
• You can see that the cursor jumps at the beginning, before "2" and the period is removed. So when you type "1", you do not get "2.1" as expected, but "12".

We fixed it by making our own custom component which checks for previous value to make sure how to handle input changes.
Perhaps we should implement such a fix in the library too? It can be built upon to handle input behaviour of all kinds.
Here's the PR for it: #1945

[miedzikd]

I had an issue related to that topic:
When you have a value like: 5.45 and then you will use backspace to remove the last two chars, at the moment when the value should be 5. it deletes also "dot" a move cursor before 5 - is not user friendly

[claireramming]

commenting to say I would appreciate a fix for this. We are running into the backspace issues in chrome.