Whenever we try to perform a send tx to an address with an ENS domain which uses emojis, like 😉️😉️😉️.eth with Nicknames disabled, we can see in 2 places how this is not correctly handled:
in the case of old transactions screens, we can see this value in the recipient xn-n28haa.eth for the last confirmation page
in both redesigned and non redesigned, after performing the transaction, we can see the recipient xn-n28haa.eth in the tx receipt
Expected behavior
I think for the old transaction screens, that could be left unfixed, since this will be fixed in the new redesigned screens.
For the transactions details, once that tx has been send, the recipient should be fixed.
Screenshots/Recordings
In the Transaction receipt, I can see the wrong "parsing" of that ENS domain:
In the non redesign transactions, I can also see the wrong parsing in the last Confirmation screen:
Describe the bug
Whenever we try to perform a send tx to an address with an ENS domain which uses emojis, like 😉️😉️😉️.eth with Nicknames disabled, we can see in 2 places how this is not correctly handled:
xn-n28haa.ethfor the last confirmation pagexn-n28haa.ethin the tx receiptExpected behavior
I think for the old transaction screens, that could be left unfixed, since this will be fixed in the new redesigned screens. For the transactions details, once that tx has been send, the recipient should be fixed.
Screenshots/Recordings
In the Transaction receipt, I can see the wrong "parsing" of that ENS domain:
In the non redesign transactions, I can also see the wrong parsing in the last Confirmation screen:
https://github.com/user-attachments/assets/c64e7b9e-43d5-4b8a-aa52-e032c6aaafd2
Steps to reproduce
xn-n28haa.ethxn-n28haa.ethError messages or log output
No response
Detection stage
In production (default)
Version
12.6.2
Build type
None
Browser
Chrome
Operating system
Linux
Hardware wallet
No response
Additional context
No response
Severity
No response