HTMLInput valueAsNumber with value = 0 returns NaN

[MiroslavPetrik]

Describe the bug
Changing input value to 0 (number literal), and reading it back with valueAsNumber returns NaN.

To Reproduce
Steps to reproduce the behavior:

// 1. test code
await fireEvent.change(input, { target: { value: 10 } }); // note passing number literal, not 'stringy-number' "10"

// 2. app code
const {value, valueAsNumber} = event.target
console.log({value, valueAsNumber}); // {value: 10, valuesAsNumber: 10}

// 3. test code
await fireEvent.change(input, { target: { value: 0 } });

// 4. app code
console.log({value, valueAsNumber}); // {value: 0, valuesAsNumber: NaN}

Expected behavior
For input value 0, the valueAsNumber should return 0.

Additional context
As workarround, I set the string value in test instead:

await fireEvent.change(input, { target: { value: "0" } });
console.log({value, valueAsNumber}); // {value: "0", valuesAsNumber: 0}

• the valueAsDate should similarly work with 0

[btea]

Maybe the code should be adjusted to:

return parseFloat(this.value);

happy-dom/packages/happy-dom/src/nodes/html-input-element/HTMLInputElement.ts

Line 778 in 47dada8

return this.value ? parseFloat(this.value) : NaN;

[btea]

@MiroslavPetrik Hello, regarding the fireEvent in the code you provided, I did a global search and couldn't find it. Can you elaborate on this usage scenario?

[MiroslavPetrik]

@MiroslavPetrik Hello, regarding the fireEvent in the code you provided, I did a global search and couldn't find it. Can you elaborate on this usage scenario?

that is example from my codebase. form-atoms/field@aab4481#diff-10a9941191519d185e1921cf27111ad8e4dd0522fd591f11857ec42035a13818R55

It points out that there is number literal -- I was not sure, whether its not bug to just fire event with number value, e.g. even real browsers have string values on number inputs...

put other way, the fireEvent.change could be typed to accept only strings...

[btea]

The value of input seems to only accept strings

happy-dom/packages/happy-dom/src/nodes/html-input-element/HTMLInputElement.ts

Line 598 in 2ea8d39

public set value(value: string) {

However, if the input type is number, should it also accept number type values? 😕

[MiroslavPetrik]

from the DOM, the value is always string, react accepts value of number type, but it gets converted by the DOM eventually

[btea]

Ok, I get it, so it's not a bug.

[MiroslavPetrik]

It certainly is a pitfall. Maybe not bug in strict sense with regards to html spec.

I would still fix it, my reasons:

1. as I can set input value to number without warning, I should be able to do so in tests with firing events having number value.
2. jsdom works in both scenarios, e.g. when I set "0" or 0. their implementation parses value right away
3. it will be more user friendly to have this covered. and so it leads to HAPPINESS

[btea]

Agree, type judgment is performed when setting the value, or the value is converted to a string by default.

[capricorn86]

Thanks for reporting @MiroslavPetrik! 🙂

Big thanks to @btea for providing with a fix ⭐

You can read more about the release here:
https://github.com/capricorn86/happy-dom/releases/tag/v8.7.1

Please re-open if the fix did not solve the entire issue.

[MiroslavPetrik]

Just installed and it works. Thanks.