Metamask-extension: Add "Confirm All" button

[wbt]

I have a dapp in which a user can update any of several fields of data stored in a smart contract.
At present, updating multiple fields (in many cases) means multiple transactions will be triggered. Due to particulars in the dapp, the first one is sent and mined before the others, often with some time for UI in between. The first one is submitted as a normal one-off transaction, but after that there might be a dozen stacked up. The top of the MetaMask interface show "1 of 12," "2 of 12," etc. with arrows allowing the user to flip between transactions pending their approval. There is a red Reject All button at the bottom. The transactions are in reverse order (reportedly going to be flipped in a fix <2 days from now).

With the limited amount of information presented, it's very hard for any user to figure out exactly which transaction does what, and they're going to want to Submit All regardless of order; requiring separate clicks on each of a dozen separate transactions is not a good UX. Consolidating into fewer transactions (base case 1) raises costs, which is not good UX either.

This Issue requests the addition of a green Submit All button, following statistics for the set of transactions that would be submitted by clicking that button (e.g. total max amount/transaction fee in ETH and USD). This would be in the blank space below the Reset/Submit/Reject buttons. The Reject All button could be placed next to Submit All.

I might also recommend some grouping by source/target address, so that only those transactions going from & to the same address pair are grouped together. In conjunction with displaying the totals, this would satisfy the UX issue in my motivating use case, while making it harder for some malicious script to hide a bad transaction in the larger set. For the easiest starting point from a UX design perspective, the "Submit All" button + statistics could appear only if there are multiple transactions awaiting user approval which ALL have the same to and from address.

When these additional elements are displayed, we may also want a checkbox next to the editable Gas Price field to apply edits to all the pending transactions, not just the first/last. However, the estimated gas limit should be allowed to remain its estimated value, different for each transaction.

I'm using Chrome on Windows 10, but this Issue filing is not meant to be browser/OS specific.

[Powersource]

We would also love a Submit All button! Right now we're giving users RSI if they donate to a lot of addresses :P

[bdresser]

relates to #5307

[wbt]

@whymarrh Thanks for taking this on! Do you have any updates on how it's going?

[Powersource]

Any update/approximation where this is on the roadmap would be appreciated :)

[wbt]

Thinking about implementation and security, I recommend that the "Confirm All" button (and maybe Reject All) be disabled/grayed out for 3 seconds each time the number of affected transactions changes.

[wbt]

For more implementation details, commits in this PR seems like a reasonable starting point for a model to consider.

[whymarrh]

This isn't something currently in development.

[wbt]

@whymarrh That's unfortunate. Is it not in development because of some particular reason why it shouldn't be developed by anybody, or just based on the idea there's no need, so it's not a priority for limited developer time?

[bdresser]

@wbt we recognize the need! Just trying to prioritize the features that will have a large positive effect on a wide portion of our userbase. Our limiting factor is design bandwidth, so thanks for the initial thinking you've done on the UX of this feature.

We've found that users are often unclear on the specific outcomes of transactions they're asked to confirm. Confirming several tx at once will compound the problem, so we want to deal with it carefully.

In the long run, we may try to move away from multiple on-chain tx confirmations and towards a model where the user can extend a set of permissions to the dapp.

[wbt]

We've found that users are often unclear on the specific outcomes of transactions they're asked to confirm.

Yes, that is definitely a problem. Having transparency like "This transaction appears to be calling TakeSomeAction(actionParam = 5, label = "Some String Parameter") on the Clearer contract at identicon 0x5155..." would be a huge improvement over the status quo. That should be tracked separately if it isn't already.

Confirming several tx at once will compound the problem, so we want to deal with it carefully.

That problem actually compounds this one. Part of the reason this issue is so frustrating is because it seems like a lot of clicking through individual transactions without anywhere near enough information to make an informed confirm/reject decision because the user has no idea what any of the individual transactions do. They are basically taking it on faith (though code inspection is also theoretically an option) that the transaction they're confirming in the MetaMask popups are logically tied to the action they just kicked off on the page. The MetaMask UI popup does not offer users a meaningful choice with interpretable options, and having a lot of these bad UI elements just leads to a tedious, frustrating UX. Are there dozens of transactions? Just keep clicking through and hope for the best, with no idea why (unless the user reads the code).

The user experience underscores how Ethereum-based blockchain dapps are frustrating and hard to use with poor UX design, slowing adoption. It doesn't have to be that way! However, no matter how good the dapp's UX designer, MetaMask is a weak link on this point.

In the long run, we may try to move away from multiple on-chain tx confirmations and towards a model where the user can extend a set of permissions to the dapp.

That also seems reasonable, and may have some symmetry with permissions the dapp extends to the user. Version 1 could even be pretty coarse, e.g. "Automatically approve all transactions with contracts at RPC endpoint/network identifiers + address with option: {total cost, sent ETH value} at or below user-defined numeric threshold." However, this seems like pretty far future, like something that should be tracked separately, and the "Confirm All" button would still be very helpful as an interim solution!

[bdresser]

Another request for similar feature with batched transactions

I currently use web3.js and the BatchRequest functionality - I would like to be able to do this but only approve once - currently it should 1 or 100 if I batch send 100 transactions and I need to approve each one separately. Is there a way of doing this which requires a user to only approve once? Present the same diagalog but with an approve all button which approves and submits the txs in the order issued on the batch.

[wbt]

Thanks for marking the dupe.

I get requests for this on a regular basis, with complaints that individually approving every transaction is far too tedious; this sort of interaction would be much much faster and easier with a traditional centralized web app architecture. Not having this feature is actively hurting usability and adoption.

I've considered a few strategies to address this problem:

1. Copying the code changes for "Reject All" to make a "Confirm All" with a little popup saying "You are about to approve X transactions to Y unique addresses with a maximum total amount of Z" with options "View Individual Transactions" cancelling out of that or "Confirm All" (again) approving. However, with the discussion about having to go through special design steps, design reviews, EIPs, etc., I don't think I could do all of that myself and have an approved PR for this Issue.

2. Having a separate fork of MetaMask just for this feature, but don't think I have the bandwidth to _maintain_ a separate fork at the moment, including security updates etc.

3. Switching from a dapp with some centralized elements that could be decentralized, to a more centralized architecture, maybe even completely centralized, because of this specific UI issue.

4. Continuing to wait on the MetaMask core team and/or open source community for something that is "not currently in development."

I disagree with the view that we should have to wait until _everything_ one might possibly want for transaction grouping should be done, including perfected design, before _any_ of it is. I think just getting this Confirm All in, even if imperfect, would be a significant positive step for usability and adoption.

On May 20:

Our limiting factor is design bandwidth

4 days ago, @chriskalani volunteered to help with design, which sounds great! This makes me cautiously optimistic about strategy 4, but very cautiously based on the history of this issue. It's been well over a year on that strategy so far with no apparent progress.

Can we please get this added in, even if it's just this specific feature without all the bells and whistles which might require an EIP etc.?

[mitar]

For me this is a problem with simple ERC-20 token, where I first call approve on it and then transferFrom (wrapped inside a call to my contract's method) to transfer tokens. If I batch them together, user still has to confirm twice, even if this is effectively just one transfer.

[illuzen]

I think going slow on this trying to protect the users is the wrong decision. Provide options to the users. If they want to click thru each transaction, they can. If they want to approve all because, for example, they trust the developer of the dapp and just want the interface to simplify their workflow, we should let them. Don't give into this paternalistic protection racket model. Our civilization has enough false fathers.

Giving dapps generic permissions sounds more flexible. But with flexibility comes more uncertainty about what the code does. Even spitting out contract source code is not going to eliminate uncertainty in many cases. Maybe some generic summary, like (this call transfers this much ether, this many tokens, calls out to these other contracts, etc.) could help, but it requires somewhat sophisticated contract inspection, and again does not eliminate uncertainty.

I may just going to copy pasta the reject all button code into a confirm all button. Shouldn't be too hard.

[mitar]

Yes, I am completely unsure what purpose those confirmations even serve. I cannot imagine any realistic user to be able to make a determination if the call is problematic or not. They can just trust the app or not trust the app. But understanding if a call should be made at that time to which address with which payload, and verify all that, I do not think this is realistic at all. So what I think is happening with this confirmation boxes is just habituating the user to just click confirm all the time.

I think a fundamentally different security philosophy should be used. Not sure which one though.

[illuzen]

If a dapp tries to transfer ether or tokens, this may be unexpected and malicious and this would be a good time to have the confirmation boxes, but in other cases, it's certainly questionable.

[mitar]

But users cannot know what a particular smart contract call does. For ether sure, you can see that ether is associated with the call. But for tokens I can always call into my smart contract method called checkBalance which then in fact transfers tokens. How will user know that this is happening without investigating the smart contract, or simply, trusting the dapp and smart contract.

I think a much better solution would be to have some rating system for dapps and smart contracts where users could collectively audit them. And be awarded for that work.

[wbt]

@mitar Permissions might also be different on a private chain vs. mainnet.

[Kellyreid]

I very much need this for batch operations in a secure environment. I understand the risk of injection but that is a non-issue in my setup.

If not an official update, is there a hack-y work-around?

[wbt]

@Kellyreid One possible hack-y workaround is if your batch operation follows a very predictable pattern, you can have a smart contract do all the calls with a single call to the batch processing smart contract. However, in many cases, the set of transactions depends on user input, so it can't be easily predicted and set in another contract.

[wbt]

From September 2019:

I may just going to copy pasta the reject all button code into a confirm all button. Shouldn't be too hard.

@illuzen How is this going? Did you find any issues that would block that path to fixing this?

Lack of "confirm all" remains an issue actively harming adoption.