As a result you send 10000 Treasure, but your recipient is delivered 10 without you suspecting anything until they react.
The problem and how I encounter it:
As an ADHD accomodation tool, I count and copy-paste larger numbers from a calculator (which adds the standard readability-improving spaces every 3 numbers) into the Treasure field:
"34 034"
Even if I click away and deselect the Treasure field, the field still says "34 034", so everything seems fine.
I triple check my trade and it is presented as correct to me (as in the screenshot), so I send it by hitting "Request Trade" button.
The trade sends as if it was all fine, so I assume everything is in order.
But it's not.
My recipient gets the CR. But they don't get the 34034Treasure I believe I attached (I triple-checked it!), they get only 34Treasure.
Of course I'd never know if they didn't react accordingly.
This means, FR cut off the space AND everything after, and this happened AFTER I clicked "Request Trade", and FR didn't even alert me of that in any way at any point!
(this happened to me a few weeks-months ago as well, with a more diverse number which let me quickly find the exact pattern this bug follows, and I bet I wouldn't remember prior repeating that mistake even if my brain wasn't ADHD. And, sadly, I'm sure I'll forget about this again... repeatedly:/)
This is surely an unintended behaviour and needs to be fixed.
FR needs to get able to deal with the spaces in a field like this in some way,
like ignoring it completely without cutting off the offered amount (the prefered fix), auto-removing it from the field (the second-prefered fix if the former is truly impossible for FR's code - spaces help!), or throwing a visible "invalid character" error at some point while preventing the user from sending the CR while the space is there (least prefered fix, or even an undesired one if the error ends up ruining the CR and forcing to start-over).
Definitely not going the troll-like stealth mode it does now, pretending that you've send the amount you've last seen in the field... just because there was a readability-improving space in it, and you didn't know or didn't remember what it does... (Especially if, like me, you are more used to the 1 000 000 format
than the 1,000,000 or 1.000.000, forget the 1000000 that is a pain to decipher, lesser or greater)
The problem and how I encounter it:
As an ADHD accomodation tool, I count and copy-paste larger numbers from a calculator (which adds the standard readability-improving spaces every 3 numbers) into the Treasure field:
"34 034"
Even if I click away and deselect the Treasure field, the field still says "34 034", so everything seems fine.
I triple check my trade and it is presented as correct to me (as in the screenshot), so I send it by hitting "Request Trade" button.
The trade sends as if it was all fine, so I assume everything is in order.
But it's not.
My recipient gets the CR. But they don't get the 34034Treasure I believe I attached (I triple-checked it!), they get only 34Treasure.
Of course I'd never know if they didn't react accordingly.
This means, FR cut off the space AND everything after, and this happened AFTER I clicked "Request Trade", and FR didn't even alert me of that in any way at any point!
(this happened to me a few weeks-months ago as well, with a more diverse number which let me quickly find the exact pattern this bug follows, and I bet I wouldn't remember prior repeating that mistake even if my brain wasn't ADHD. And, sadly, I'm sure I'll forget about this again... repeatedly:/)
This is surely an unintended behaviour and needs to be fixed.
FR needs to get able to deal with the spaces in a field like this in some way,
like ignoring it completely without cutting off the offered amount (the prefered fix), auto-removing it from the field (the second-prefered fix if the former is truly impossible for FR's code - spaces help!), or throwing a visible "invalid character" error at some point while preventing the user from sending the CR while the space is there (least prefered fix, or even an undesired one if the error ends up ruining the CR and forcing to start-over).
Definitely not going the troll-like stealth mode it does now, pretending that you've send the amount you've last seen in the field... just because there was a readability-improving space in it, and you didn't know or didn't remember what it does... (Especially if, like me, you are more used to the 1 000 000 format
than the 1,000,000 or 1.000.000, forget the 1000000 that is a pain to decipher, lesser or greater)