Metamask incorrectly estimates gas if destination address is entered first, but estimates correctly if amount is entered before address.

[glitch003]

Describe the bug
When sending to a contract with a fallback payable function, Metamask incorrectly estimates gas if destination address is entered first, but estimates correctly if amount is entered before address.

To Reproduce
Steps to reproduce the behavior:

1. Open metamask on mainnet
2. Click on Send
3. Paste this in as the recipient address: 0x77B6fB0cC1022bD7838023211F4dcDdC385856F5
4. Enter an amount (any amount should work but I use 0.01)
5. Observe that gas limit is now ridiculously high (7600027)
6. Now close metamask and open it again
7. Click on Send
8. Enter an amount (any amount should work but I use 0.01)
9. Paste this in as the recipient address: 0x77B6fB0cC1022bD7838023211F4dcDdC385856F5
10. Observe that gas limit is now correct (88516)

Expected behavior
Metamask should set the gas limit correctly regardless of whether the user enters the address or amount first.

Browser details (please complete the following information):

• OS: OS X 10.13.6
• Browser: Chrome Version 70.0.3538.110 (Official Build) (64-bit)
• MetaMask Version: 5.1.0

Additional context
Here's the contract source for reference https://github.com/deconet/DeconetPaymentsSplitting/blob/master/contracts/DeconetPaymentsSplitting.sol

[d10r]

Is there any technical documentation (or good place in a source file) for looking up how Metamask currently determines the gas limit?
I've repeatedly observed seemingly random behavior, with Metamask setting the gas limit sometimes too low, sometimes too high, while at the same time I had reliable estimates when using web3.eth.estimateGas() and web3.eth.Contract.methods.estimateGas() (e.g. in a truffle console) for similar interactions.
How does Metamask determine the pre-set value for gas limit and what triggers this calculation?
May it be that there's possible race conditions, leading to different outcomes for the same user input?

In my case, the behavior described here (estimate correct if amount set first) would already be an improvement. Instead unfortunately, regardless of the order of data entry, the estimate may be good or bad. As if there were possible race conditions.
I'm using the latest Metamask with Chromium on Linux, but have seen similar issues on other browsers and operating systems.

I already looked into the option of using EIP-861 URLs / QR-codes in order to allow non-technical people to avoid gas-related issues when using Metamask for interacting with contracts (at the moment just plain ETH transfers, which however trigger logic of fallback functions), but that seems to not be supported either (Metamask reads the receiver address, but ignores the encoded gas settings).

[fedealconada]

I confirm I'm having the same issue as @glitch003. To add up to the information provided by him, the problem seems to happen when the recipient address is a contract. Maybe @danfinlay can help us with this.

[danfinlay]

Is there any technical documentation (or good place in a source file) for looking up how Metamask currently determines the gas limit?

The method estimateTxGas here: https://github.com/MetaMask/metamask-extension/blob/develop/app/scripts/controllers/transactions/tx-gas-utils.js#L57-L104

[mariowillems]

What adress is 0x77B6fB0cC1022bD7838023211F4dcDdC385856F5 actually?
Accidently send BNB to it...