Safe-react: The error message and Contract Address name are displayed in the same line

[alongoni]

Title/Description

The error message and Contract Address name are displayed in the same line

Environment

• Browser: Chrome
• Safe:
• Wallet:
• App Version: 3.2.0
• Environment:
  
  
  
  • dev (rinkeby)
  
  

Steps to reproduce

1. Go to 'New transaction' button. Then 'Contract interaction'
2. Complete Contract Address input with '0x5eC429cB23bC903DeeB8112334a576A0c091a7d0'

Expected result

The error and the name should not overlap each other

Screenshots

[alongoni]

hi @tschubotz. Is there a way we can rephrase this message (in a shorter way) without losing the meaning?
"Input must be a valid Ethereum contract address, ENS or Unstoppable domain"

If the message is ok, I will see how it fits correctly in the input.

[tschubotz]

hmm.
What about Must be valid Ethereum address, ENS or .crypto domain?

[francovenica]

@tschubotz We thought about something more generic like: "Must resolve to a valid smart contract address" , in case we support another type of address at some point

[alongoni]

@lukasschor What do you think about this generic error message?: "Must resolve to a valid smart contract address"

[lukasschor]

I think this should actually be two separate error messages:

Case 1: Input is not a valid Ethereum address, ENS / Unstoppable domain: "Must be valid Ethereum address, ENS or .crypto domain"

Case 2: Input is a valid address or domain, but the underlying Ethereum address is not actually a smart contract: "Must resolve to a valid smart contract address" or "Address is not a smart contract"

If that would be more complex to implement, we can just go for "Must resolve to a valid smart contract address" in both cases.

[fernandomg]

@lukasschor, we decided to go with the generic error message.

If we go with the different cases approach, despite it adds a bit of complexity to the implementation, we are not covered for facing the same issue in the future if another source of Eth Address resolution is supported.

We can think of adding a more detailed error message in a different way, other than inside the input.

/cc @dasanra