fixed amount input field to properly interpret BTC

[amitx13]

This PR fixes #799
Fixed the amount input field to correctly interpret 1.0 as 1 BTC. Previously, it was incorrectly treated as a much smaller value; for example, entering 0.1 was considered 0.00000001 BTC.

[0xSaksham]

This is the most important thing mentioned by edi. It works great now!

[editwentyone]

fixed, thank you

[amitx13]

Hey @theborakompanioni, if you have a moment, could you please take a look? I added a test case for BitcoinAmountInput and used a slightly different approach compared to what was previously used in the tests. The reason for this change is that using await user.type(inputElement, '1.0') was interpreting 1.0 as 1, which ultimately resulted in sats being displayed. Instead, I used fireEvent to handle this scenario.

[amitx13]

I've updated the BitcoinAmountInput component to only accept . as the decimal separator. I understand that restricting users to one separator may not be ideal, but this approach effectively solves the issues with BitcoinAmountInput and its related test cases.

[editwentyone]

I've updated the BitcoinAmountInput component to only accept . as the decimal separator. I understand that restricting users to one separator may not be ideal, but this approach effectively solves the issues with BitcoinAmountInput and its related test cases.

so will there be a solution in the future where we can differ between , and . as the separator to be l11n friendly?

[amitx13]

so will there be a solution in the future where we can differ between , and . as the separator to be l11n friendly?

Well in the English number format, JavaScript only accepts . as the decimal separator. To use , as the separator, we would need to change the number format to Italian. However, even if we change the number format to Italian, JavaScript will still interpret , as . for parsing purposes. The issue arises with inputs like 1.0 or 1,0 because JavaScript interprets it as 1, which is correct generally but not in the context we need

[editwentyone]

ok got it, lets keep it at . for the time being

[theborakompanioni]

Okay, @editwentyone, as @amitx13 has argued, making it a text input only (as opposed to a number input) increases consistentcy between browsers, but lacks the ability to use browser-native up/down arrows.. I can see that this is a reasonable trade-off - what do you think?

[editwentyone]

absolutely. good idea, I bet no one uses the arrows anyways!

[amitx13]

absolutely. good idea, I bet no one uses the arrows anyways!

Then, the only thing holding up the PR now are the reviews.