Surprise "Confirmed!" screen popping over interface; long spinner on clicking OK

[wbt]

Summary
The confirmation in PR #4363 seems to be appearing in situations other than when gas prices are being adjusted for transaction retry, and presents confusing language. Clicking "OK" leads to an infinite spinner.

Details
I'm getting feedback from a dapp user, connected to Geth on a private PoA network, with no noticeable interruptions in connectivity. This was a private PoA network, with only one user issuing write transactions around the time of the issue. The dapp has been pretty reliably issuing transactions that get mined on the network. The user was not using MetaMask to reissue any transactions or make any gas price adjustments, just triggering transactions in the dapp as designed. The user was seeing the following popup:

Clicking OK, this is what showed up:

This spinner was displayed for 20 minutes before the user closed MetaMask notifications. The user then continued to interact with the dapp to issue transactions, and presumably approve them. These green checkmark confirmations kept coming up. Clicking "OK" led to spinner, clicking anywhere else just dismissed the confirmation, and ignoring the "Confirmed" notices led to them "just going away" after a short while. After concluding the intended set of interactions, the user noticed that several confirmation screens showing grayed-out content with the white box and green checkmark + confirmed message were stacked up at the bottom of the screen. Inspection of the dapp and blockchain shows the user's transactions were confirmed as expected.

Failed reproduction attempt
Attempting to reproduce, I went to the same dapp and issued a transaction. I noticed that the transaction remained "Pending" in Metamask for several minutes. Inspecting the page console, I found an error "Transaction wasn't processed in 240 seconds!" I refreshed the page. The transaction had not been mined. Inspecting the blockchain with a more direct call also showed the old data and the transaction still showed as Pending in MetaMask. Using the dapp, I set up another transaction to have the same effect as the first, and confirmed it in a MetaMask popup. Then I had two pending transactions, 11 minutes apart, not getting confirmed. Clicking to view details, I saw a "Speed up" button on the first but not the second transaction, and "cancel" options on both. The second one looked like this:

Notice that the numbers above the identicon are different for the two transactions, suggesting they are different transactions. The dapp logic permits both to proceed without error, setting a storage slot to a specified value. Doing it more than once means extra gas cost without corresponding benefit, but these ETH are pretty much free. It's interesting to note the Activity log saying the transaction was "submitted with gas fee of 0 WEI" when the gas price a few lines above cites a 1 GWEI gas price.
Refreshing and setting up a third attempt, I took a screenshot of the confirmation screen:

This looks a bit different than previous, such as the "No conversion rate available" text, maybe extra vertical whitespace (note that vertical scrollbar on the right and how close the buttons are on the bottom). Also, the large 0 is apparently the amount being sent in the transaction; the account balance shown is quite large (many ETH). Clicking "Edit" on the gas fee, I got this screen, which doesn't show the full width:
.
The Advanced tab shows gas price = 1 GWEI, gas limit = 94587. I then clicked Close and Confirm, and had three pending transactions. 4 minutes later I got the same error in the console.
When I'd been at five pending transactions for over an hour, I reset the account, reloaded the page, and re-triggered the transaction, which was promptly confirmed. So I suspect I was encountering a separate issue there (maybe #4086), but decided to leave these details in the Issue report in case it is conveying useful signals about how the dapp works (default gas price etc.).

For background, the dapp disables the transaction-triggering button as a first step when that button is clicked, to prevent the same transaction content from being submitted more than once by accident. To submit the same-transaction content, the page needs to be refreshed and/or the transaction confirmed.

Language
As a secondary issue, the language in this message, "Click OK to go back" is not clear to the user about what it does. Does that go back one step in the application workflow? (No.) Does it cancel something the user had tried? Does it just dismiss the dialog? If the latter, the message should be clearer, or maybe just drop that second sentence. Reading the PR to see this was intended for retry requests, the first sentence leaves me wondering if the first transaction (with presumably a lower gas price) succeeded, as described by the text ("Your initial transaction was confirmed by the network") or the retry version with the presumably higher gas price, as suggested by a cursory read of the PR (which most people won't see). I'm even more confused about why this showed up at all because no transactions were retried.

To Reproduce
I do not yet have reliable reproduction steps, unfortunately.

Expected behavior

1. No green-check-mark confirmation screen referring to an initial transaction, on confirmation of a regular transaction in the workflow.
2. No stacking up of such popups/boxes at the bottom of the screen.
3. Clearer language in the message about what it means and what next action the user can/must take
4. Clicking "OK" doesn't bring up a spinner.
5. If there is a spinner, it shouldn't last so long (over-a-year-old #3253) and should give the user some clue about what is/isn't happening.
6. Content generally fits on the screen/within the display, especially when plenty of screen space is available.

I looked at a bunch of other infinite spinner issues before filing this one, but the others seemed likely to have other causes like network disconnection, network change, initial permissions granting, and none seemed to be a good match for this issue. I'll return to update/comment below if I find more details, especially if I can get reliable reproduction steps.

Browser details:

• OS: Windows 10 Pro
• Browser: Chrome
• MetaMask Version 6.2.1

[bdresser]

Thanks for the writeup @wbt

We haven't been able to reproduce the main issue with the spinner and confirmation window. Let us know if you experience it again and are able to share reliable reproduction steps.

The "0 wei" issue is fixed by #6301

We're steadily working on a variety of cosmetic / layout fixes that should reduce the unnecessary scroll bars you see.

Could you clarify what screen your comments about "Click OK to go back" apply to?

[wbt]

@bdresser
The first screenshot in this Issue shows the sentence "Click OK to go back." The "language" section applies to that.

[wbt]

It was suggested here today that the unexpected treatment of new transactions as resubmissions could be the result of an incorrect nonce calculation, especially if the nonce is too low. Reproduction might involve having two instances of MetaMask or another means (e.g. a truffle migration) of submitting transactions from the same imported account. I'm a bit stacked up and won't be able to test that today, however.

[wbt]

Further investigation suggests the possibility that some transactions may have been submitted from a different browser (which I'll call Browser B, if the issue is observed in Browser A), using the same private key (imported account). It may be that Browser A received notice of those transactions succeeding, but Browser A didn't have record of sending them, and displayed this malfunctioning popup. There was probably a more-than-sufficient-for-mining time delay from the submission of transactions in Browser B to the use of the same dapp in Browser A.

[Gudahtt]

I encountered this sometime last year. I investigated the UI logic for when this component would appear, and I recall it being pretty messy. It's unclear if this is still an issue as it's intermittent and difficult to reproduce consistently, but either way we should clean up the UI logic to ensure mistakes like this are no longer possible.

[danjm]

The confirmation modal in question here has not been in use for a long time. Closing