If your "locale" uses decimal comma like "123,45" instead of "123.45", NaN crashes the whole kitty about freecount HOT 9 CLOSED

"kitty" = common pool of money (Deutsch: Gemeinschaftskasse. Onboard yachts: Bordkasse)

from freecount.

Hi, thanks for reporting. So to understand better:

• Your browser locale is set to German
• You can add an expense of say 123,45 and the form lets you add it
• Then the computation breaks because it can processed the NaN

Is that correct?

I will first try to make a better validation for the amount, right now it just relies on the <input type="number"> whose support varies between browser. But then I am trying to figure out if one can take the locale into account to parse the number correctly. I would expect it to be handled by the input, but apparently not.

from freecount.

Yes. Yesterday, we had the first real use case, and after adding an "incorrectly" formatted amount, the whole sheet crashed - unfixable, this is the most important thing. So I suggest to fix it two-fold:

• try to detect the correct locale ;and
• just in case, that a NaN occurs, try to fix this, to reduce the impact. Of course, NaN should be fully avoided.

from freecount.

Now, when I enter "1,23", I got this

Uh, not nice. You now could tell the user: please use "." as decimal separator - or you simply substitute that character (be aware of possible problems with the "." when someone uses that "." as a digit grouping separator like in "123.456,78").

from freecount.

Hi, thanks for your help. So I did a little fix just to avoid breaking the count all together if an invalid number is entered. I am now looking into validating at the time of the input.

But I was still expecting the form to do some kind of validation. Could you tell me what device/browser you are using?

from freecount.

It should now be fixed as of 9720945, which adds a much better form validation. Depending on the browser / locale, using , for decimals is actually understood correctly when entering a number (tested with Safari/iOs in German and Chrome/Andoid in French), and I am planning to rely on the native way browsers do it without interfering at the code level.

Thanks for your valuable feedback!

from freecount.

I only use Firefox, and unfortunately, the detection appears not to work. I mena, when I enter "1,23" the box shows a small red border and I have to retype as "1.23" to get that in.

https://freecount.s10a.dev/?box=50470e168b046fdcf6a0b5bc71ef1bf8

from freecount.

I see, I my Desktop Firefox also considers "1,23" as invalid. But the mobile versions seems to handle it, which is the main target.

I could do something fancy about it in the future (pointing that it is a decimal symbol issue, or even substituting on the fly) but for now I want to just rely on what is a valid/invalid input from the browser's point of view, without making assumption about the user intent.

from freecount.

It should work on both Firefoxes in the same way.

from freecount.