After approving an EIP-681 "approve" request, MetaMask Mobile version 1.06 continues to display "Waiting for confirmation" even after the transaction is successfully completed on the blockchain

[ravisriv]

Describe the bug
This has reference to EIP681 feature #1847 and the items described under #1980

MetaMask mobile (version 1.06 on iPhone X iOS 14.1) continues to show "Waiting for confirmation" message, even after an EIP681 "approve" request has been successfully executed on the blockchain (11 block confirmations are received). On certain occasions, the "approve" request does not appear immediately under the "Transaction History" (occurred twice in 4 tests). Two of the EIP681 "approve" requests, which I approved, appeared under the Transaction History after almost an hour. Both on them were showing the status
"Approve
Submitted"
But the status of both on the Rinkeby Etherscan was "Success".

Screenshots
Here are the screenshots:

To Reproduce
Steps to reproduce the behavior
Use https://brunobar79.github.io/eip681-link-generator/# to create a deeplink for "approve" function. Scan the QR code using MetaMask mobile version 1.06.
Alternatively, you can email a request of the following type to your smart phone and click on the deeplink to invoke MetaMask.
https://metamask.app.link/send/Token-address@Netid/approve?address=saleContractAddress&uint256=approvalAmount
Token-address is the address of the token that will be approved to be spent by the saleContract.
Netid is 4 for Rinkeby (test) and 1 for Ethereum Main (production)
saleContractAddress is the address of the saleContract, which is approved to spend tokens
approvalAmount is the amount for which "approval" is sought

Expected behavior
After 6 confirmations on the Rinkeby blockchain, the MetaMask mobile should stop displaying "Waiting for confirmation." The message should display "Transaction confirmed". After that under the Transaction History, it should show:
"Approve
Confirmed"
This should happen as soon as the required number of blockchain confirmations are received.

Smartphone (please complete the following information):

• Device: iPhone X
• OS: iOS 14.1
• App Version: 1.06

---

to be added after bug submission by internal support / PM
Severity

• How critical is the impact of this bug on a user?
• Add stats if available on % of customers impacted
• Is this visible to all users?
• Is this tech debt?

[omnat]

Hi @ravisriv thanks for your detailed report. Could you please try to update to 1.0.7 and see if the issue resolves?

[ravisriv]

@omnat Certainly, Omna! Would be a pleasure to test 1.07. Will run all the tests and report back. Thank you!

[ravisriv]

Hi @omnat - I tested MetaMask mobile v1.0.7 and it continues to have the same issue. When the EIP-681 compliant deeplink is executed from the email app on iPhone, MetaMask does not get a confirmation from the blockchain. In addition, when a QR code deeplink is scanned from MetaMask mobile v1.0.7, we continue to have the same issue. MetaMask continues to wait for a confirmation. On the other hand, when a deeplink is executed through an app, it is successful and MetaMask gives a message of "Transaction complete". So out of 4 tests, 3 failed and 1 succeeded. Will find out what's the difference between the deeplink, which is executed from the email (or QR code) and the deeplink that is executed through a mobile app. I also noticed some usability issues and 1 bug. I'll create separate items for these.

Update on why 1 test succeeded

The reason Test #2 (deeplink executed from a mobile app) succeeded was because the deeplink in that app was not using "@chain_id".
So EIP-681 request has the following form:
erc831_part target_address [ "@" chain_id ] [ "/" function_name ] [ "?" parameters ]
Looks like the request works without optional "@"chain_id part above. But if chain_id is included, it keeps on waiting for the confirmation.

Here are the screenshots of testing with comments for anyone who is interested:

[ravisriv]

Some preliminary tests show that MetaMask Mobile v.1.0.8 (build 554) on iOS 14.2 does not fix this issue. Will take a deeper look at v.1.0.8 later next week.