In D15981#361661, @bytesofman wrote:

In D15981#361647, @emack wrote:

The effects of D15972 seems to have regressed here, allowing scrolling down when there is no content below.

could you show an example?

but also, imo the flickering is much worse than the extra scrolling. The extra scrolling situation still needs another patch anyway to deal with the size of other non-footer elements.

Minor nit not for this diff, but should add "XEC" to the Airdrop label, otherwise it looks like it was an eToken airdrop.

On a related note, are we sticking with the whole parent vs child terminology all the way through to the frontend? I recall back in 2021 there was discussion on using more user friendly terminology in the frontend, like using "Collection" for parent and "NFT" for child. This way it'll be a smoother experience for users who are used to NFT terminology from other chains.

The effects of D15972 seems to have regressed here, allowing scrolling down when there is no content below.

Can you send some ALP and NFT parent tokens to ecash:qzz0p9yux89uvgnq86u5qnztver6u7g0vqc65920xr pls? thx.

It still scrolls, albeit by a negligible 1px or so, across both mobile and web. Not a blocking issue.

This is already the behavior in prod isn't it? Toggling another send token function will disable all others.

It's not routing for me as the createdTokenId is always coming up as null in the console logs.

Tested fine on desktop and extension, but on mobile it's got some cray cray clipping happening on the onboarding screen

Accepted with minor nit on function name.

Minor non-blocking nit:
Use the existing shading in prod for the horizonal separator between txs. It's obvious enough to be a separator but not too obvious that it starts adding to the busy-ness of the screen.
Prod

Also the existing horizontal lines separating each tx should be retained, otherwise each grouping of info is not immediately obvious.

Since this diff touches on how refreshAliases is called in useWallet, can you patch the bug where right after a registration broadcast the pending alias is not immediately added to the pending aliases list, but navigating away and back to the alias screen fixes it? From a glance one of the useEffect() blocks needs to have a dependency on the aliases.pending map coming out of useWallet, so that once it is added to the pending list it can call refreshAliases.

Possibly there is the same address twice in your contact list from testing

That was it

The issue I can see with this feature is the process of killing a zero is never a one off event. You could have the scenario where we go months on end where the price is constantly killing and reviving a zero, which would result in wallets being inundated with these alerts. One mitigation would be to introduce this with a toggle in General Settings, so users who don't mind frequent alerts can explicitly switch it on. And if they get sick of it then have the option of disabling it.

It allows duplicate contact names to be added (with different addresses). If they have a long contact list this might become hard to manage. It's the case in prod as well but if we want to check on unique contact names it might be fine to do it in this diff.

Manual op_return raw input works well

TokenListItem isn't liking this

• Unit tested helper function to get circulating supply
• Unit tested helper function to get (net) burn or mint
• Implement functions
• Clean up rendering (spinner instead of "Loading..." ?)

Now if you enter in an invalid message (i.e. over length limit), then close the message toggle, the Send button is disabled even though theoretically it should be sending the tx without the message.

Is the following expected behavior?

1. fill in valid address, amount and message
2. close the message toggle indicating the user has changed their mind about sending this with a message
3. click send and observe on the explorer that the message was sent anyway

As per tg chat

This is the same in master.

I'm getting little squares where there would have been -0 XECs. Is this a font thing?

Subject to some material rebases

subject to rebasing to latest changes to txHistory parsing and sendToken UI

version bump and rebase

How do you feel about using a carousel type UI to browse through the list of tokens? It's something that NFT wallets in ethereum uses to great effect because the UI size is ringfenced regardless of how many tokens you have.

In D15810#357697, @emack wrote:

grep -r console.log src/ -- still a few left, but they are removed in D15804

Still seeing two remaining in useImage even though D15804 has since landed