That's odd, I thought I rebased this on the parent commit just before landing it. Will rebase again.

couple of issues

1. Paste ecash:qrh3ethkfms79tlcw7m736t38hp9kg5f7gycxeymme?amount=100&op_return_raw=0401020304&addr=qz252dlyuzfqk7k35f57csamlgxc23ahz5accatyk9&amount=300&addr=qzrseeup3rhehuaf9e6nr3sgm6t5eegufuuht750at&amount=200 into Send

Everything generates fine

Delete it -- OP_RETURN input remains. no blocker but probably not the behavior we want here.

2. Paste ecash:qrh3ethkfms79tlcw7m736t38hp9kg5f7gycxeymme?amount=40.00&label=test&amount=30.00 into send screen

Get multiple error notifications. I actually cannot click them all closed so that I can delete the bad string, because they keep popping up.

In D15250#342812, @bytesofman wrote:

Delete it -- OP_RETURN input remains. no blocker but probably not the behavior we want here.

I'm trying to think of a solution, but that issue is not simple. Maybe the payment URI should be its own separate widget (that could be hidden and only appear when the user pastes a non-trivial URI into the "pay to" field), that when filled causes the other ones to become slaves to the URI widget. But are users still allowed to manually change anything in the other fields to adjust the transaction, or do they become read-only as long as the URI field is not cleared?

Definitely not going to happen in this diff, and it would probably be good to have the opinion of a professional UI expert one of these days.

In D15250#342968, @PiRK wrote:

In D15250#342812, @bytesofman wrote:

Delete it -- OP_RETURN input remains. no blocker but probably not the behavior we want here.

I'm trying to think of a solution, but that issue is not simple. Maybe the payment URI should be its own separate widget (that could be hidden and only appear when the user pastes a non-trivial URI into the "pay to" field), that when filled causes the other ones to become slaves to the URI widget. But are users still allowed to manually change anything in the other fields to adjust the transaction, or do they become read-only as long as the URI field is not cleared?

Definitely not going to happen in this diff, and it would probably be good to have the opinion of a professional UI expert one of these days.

In Cashtab this is handled by

• If there is a bip21 URI with the amount param set, then the amount input is set by the bip21 uri and user modification of the amount field is disabled
• If the amount param is removed from the bip21 URI string (or the whole bip21 string is removed), amount param is cleared and ready to accept input
• If there is a bip21 URI with no amount param, then the amount field is available for user input

• If there is a bip21 URI witht he op_return_raw param, then the cashtab message input is not rendered
• If there is a bip21 URI with no op_return_raw param, then the cashtab msg input is available for user input
• If `op_return_raw_ is removed from the bip21 URI string (or the whole bip21 string is removed), cashtab msg input is available for user input

the whole thing is pretty complicated, and this is in React which is optimized for implementing and testing this sort of UI issue.

It's probably not a big deal to leave OP_RETURN populated if some input there was received, as the field is still present and visible to the user.

In D15250#342822, @PiRK wrote:

In D15250#342812, @bytesofman wrote:

I actually didn't think of interactively testing the ones that are supposed to fail. Good catch.

This issue appears to exist in electrum before this diff, at least I get the same thing when I run ecash:qrh3ethkfms79tlcw7m736t38hp9kg5f7gycxeymme?amount=40.00&label=test&amount=30.00 through 5.2.11

In D15250#342965, @PiRK wrote:

automatically clear the "pay to" field when the URI is malformed, otherwise it will keep raising the same error as the text is changed while the user attempts to correct it.
I don't expect people to manually type payment URIs, they will be copied and pasted, so this should not cause any loss of data.

Is it possible to handle this without clearing the input? It's pretty difficult to troubleshoot a bad URI string with this behavior. The error msg appears, just says it's invalid, then clicking ok resets everything.

It is better than the current behavior and possibly acceptable for electrum which is more power-user focused (again this issue exists in the prod version already and I don't think we've ever had a complaint about it). We don't want to re-engineer the whole UI for something that isn't having a real world impact.

If we can keep the bad bip21 string in place without throwing constant error msgs without a major refactor, though, it is probably worth it.

In D15250#343017, @bytesofman wrote:

especially the exotic ones such as ecash:?op_return_raw=04deadbeef

Spec does seem to be ambiguous about whether or not the initital address param is required. In Cashtab, the address param is de facto required, e.g.

You can't send anything until you add the address param, and in this config it can only be added in the URI string.

Entering this in Electrum-ABC works but it's pretty confusing to the user, as the input itself simply disappears after adding the params to the tx:

In this case, we probably want the input to persist so we know what happened and why. I'm not sure on easiest solution to this. Probably just require bip21 strings to have an address.

Not having any address seems to address some use cases, though.
The obvious one is ecash:?r=... : BIP72 payment URI that is not BIP21 backward compatible. BIP72 explicitly states that the address and amount can be ignored in the presence of a payment request url.

The other one is wanting someone to send some OP_RETURN data tx on chain without other XEC outputs. Not sure if this is a real-world need, but it was part of the rationale for https://github.com/Electron-Cash/Electron-Cash/pull/1127
I don't think we need to add this to the BIP21 spec unless someone starts relying on it for a use case, but I also don't see a good reason not to support it in Electrum ABC.

In D15250#343021, @bytesofman wrote:

If we can keep the bad bip21 string in place without throwing constant error msgs without a major refactor, though, it is probably worth it.

I need to think this through. The obvious solution is to not throw an error message as a popup, but we still need to raise the reason for the failure to parse the URI to the user in some other way (some kind of status bar or a unique non-modal error message)

.