Include spender and contract address on Approve screen

[rsmylskibc]

When using the new Metamask UI - when you make a token approve call, when Metamask pops up, the To Address is the spender address, not the ERC20 token contract address.

This is misleading because once the transaction has processed, and is in your transactions list, the To address of that transaction shows as the ERC20 token contract address (as expected, as that's where it was sent)

This has caused considerable confusion for users of the new version of our product with no clear way to reconcile. Metamask's UI presents a window that says it is about to send "to" address spender, then immediately after presents the transaction list with address token, on the surface leading some of our users to ask if the product was compromised ("why did it send to a different address?").

To Reproduce
Steps to reproduce the behavior:

1. Make an approve call to an ERC20 token contract
2. Observe the various addresses shown in Metamask
3. Confirm the transaction
4. Observe that the To address in the transaction that is in the transactions list shows a different address than what was shown in the Confirm Transaction popup.

Expected behavior
The To address in Metamask should match with the To address of the processed transaction.

Improved UX/UI to better indicate the nature of an approve transaction is great, but should be a lot more straightforward and done in a way that isn't misleading or that could indicate to a less experienced user as possibly being hacked/having their transaction compromised.

Screenshots

Browser details (please complete the following information):

• OS: OS X
• Browser: chrome
• MetaMask Version: 4.9.3
• New / Beta UI?

[bdresser]

Thanks for the feedback @rsmylskibc. We've started showing the spender since it's the address that will be able to actually spend the user's tokens - but you're right, this doesn't match what's shown in Etherscan and I get why your users are concerned.

We should probably show the contract address the To field, then include the spender address in a separate UI element (or as part of the warning message).

Sorry for the confusion this has caused your users - we're continually iterating on this particular screen to make sure folks are informed and the implications of their actions are clear.

[bschorchit]

Closing as this has been fixed since.