Bridge back to stellar - max amount chosen by the user allow for the amount that is incompatible

[Sharqiewicz]

What:

Context When choosing 'Back to Stellar' and entering 'Max,' the amount prefilled by the system is half the available funds and correct, but the error message after the transaction is signed indicates that the amount is incompatible.

• The system should choose compatible amount when user clicks "Max" and the transaction should succeed.
• The system should prefill the maximum available amount with the correct decimal number limited to 7.

How:

✅ Implement maxDecimal to be also applied for StandardFrom AvailableActions

[netlify[bot]]

✅ Deploy Preview for rococo-souffle-a625f5 ready!

Name	Link
🔨 Latest commit	b2174b06a87e432ca3ebcff150f23c8714bf62b2
🔍 Latest deploy log	https://app.netlify.com/sites/rococo-souffle-a625f5/deploys/667c476d17bae900083eece9
😎 Deploy Preview	https://deploy-preview-506--rococo-souffle-a625f5.netlify.app
📱 Preview on mobile	Toggle QR Code... Use your smartphone camera to open QR code link.

---

To edit notification comments on pull requests, go to your Netlify site configuration.

[ebma]

I noticed another bug:

1. Enter any amount with 7 decimals in the input field for issuing/redeeming with Spacewalk. Let's say: 1.1234567
2. Put the input cursor anywhere in the input field.
3. When entering a new digit, the cursor will jump to the end and replace the last digit. However, I should be able to add/change the digits in front of the ., even if the number already has 7 decimals.

[Sharqiewicz]

@ebma Excellent catch, I am working on it ✅

[annatekl]

@vadaynujra can you please test once done?

[Sharqiewicz]

@ebma I refactored the whole implementation of NumericInput events handling.

• Fixed the onPaste event to restrict invalid values.
• Unified event handling into a single onChange handler, reducing the code by 30 lines.
• Enhanced and extended test cases for NumericInput.

Please take a look and let me know if everything is right.

[annatekl]

I was testing again on the same deployment link @Sharqiewicz and while manual input is correct the error with the cursor jumping to the last digit is still there and additionally when clicking on max there is the infinit number as in the attachement

[Sharqiewicz]

@annatekl The photo isn't loading. The cursor jumps to the end of the number only if the number already has a maximum decimal and the user overwrites a new number in decimal part (without using backspace first) - otherwise the cursor doesn't jump around. What is the expected behaviour here?

Now it works like this: (max decimals is 7) ( | is the cursor )

• User puts: 1.2345678|
• User focus cursor between 2 and 3: 1.2|345678
• User puts value 9: 1.2934567|

As the user tries to exceed the maximum number of decimal places, the decimal part of the number (starting from the changed second position) is moved by one. Therefore, the cursor has moved to the end, because the entire decimal part is changed

If user uses the backspace case:

• User puts: 1.2345678|
• User focus cursor between 2 and 3: 1.2|345678
• User uses backspace: 1.|345678
• User puts value 9: 1.9|34567

[vadaynujra]

Based on the explanation, I could imagine this to be the expected behavior. @ebma do you expect the cursor to stay at the same place also in the first case?

[ebma]

I think the input field works great now. @annatekl shared a screenshot where the input was filled with 2.5164e-8 after clicking the MAX button. I can't reproduce because I don't have an account with that balance.

@Sharqiewicz can we maybe have a test that simulates the behaviour of MAX when a user has a balance of 0.000000025164 (decimal) ie. a raw balance of 25,164 units?