Defaults have been added for all three preferences. The default values
added are both falsey, so this shouldn't result in any functional
change. This was done to help make this preferences more easily
discoverable.
The max listener count of the preferences store has been increased to
12. Recently the 12th listener was added, which resulted in console
warnings during the unit tests - this prevents those warnings.
The default max listener value is 10; we didn't see this warning until
now because one of the twelve listeners is only setup when 3Box is
enabled, which doesn't occur during our unit tests.
Add alert suggesting that the user switch to a connected account. This
alert is displayed when the popup is opened over an active tab that is
connected to some account, but not the current selected account. The
user can choose to switch to a connected account, or dismiss the alert.
This alert is only shown once per account switch. So if the user
repeatedly opens the popup on a dapp without switching accounts, it'll
only be shown the first time. The alert also won't be shown if the user
has just dismissed an "Unconnected account" alert on this same dapp
and account, as that would be redundant.
The alert has a "Don't show me this again" checkbox that allows the
user to disable the alert. It can be re-enabled again on the Alerts
settings page.
All transaction status updates were moved into a `setTimeout` callback
and wrapped in a `try...catch` block in #4131, apparently in an attempt
to prevent failures in event subscribers from interrupting the
transaction logic. The `try...catch` block did accomplish that, but by
putting the status update in a `setTimeout` callback the operation was
made asynchronous.
Transaction status updates now happen unpredictably, in some future
event loop from when they're triggered. This creates a race condition,
where the transaction status update may occur before or after
subsequent state changes. This also introduces a risk of accidentally
undoing a change to the transaction state, as the update made to the
transaction inside the `setTimeout` callback uses a reference to
`txMeta` obtained synchronously before the `setTimeout` call. Any
replacement of the `txMeta` between the `setTxStatus` call and the
execution of the timeout would be erased. Luckily the `txMeta` object
is more often than not mutated rather than replaced, which may explain
why we haven't seen this happen yet.
Everything seems to work correctly with the `setTimeout` call removed,
and now the transaction logic is easier to understand.
The unconnected account alert can now be disabled. A "don't show this
again" checkbox has been added to the alert, which prevents that alert
from being shown in the future.
An alert settings page has been added to the settings as well. This
page allows the user to disable or enable any alert.
This controller was not used. It was used by the
`ComputedBalancesController`, which was removed in #7057 (as it was
also unused).
The pending balances calculator was only used by the balances
controller.
The inactive timer was being reset upon any change to the preferences
store. The intent was only to update the timer when the auto-lock
timeout had changed, so the subscription was updated to only update in
those cases.
There are no indications that this had any effect upon the user. It
looks like the preferences store never updates while the extension is
unattended, so in practice this may have been harmless. It was still
pointless however. This also protects against the possibility of the
preferences store being updated while unattended at some point in the
future.
A race condition exists where after adding an unapproved transaction,
it could be mutated and then replaced when the default gas parameters
are set. This happens because the transaction is added to state and
broadcast before the default gas parameters are set, because
calculating the default gas parameters to use takes some time.
Once they've been calculated, the false assumption was made that the
transaction hadn't changed.
The method responsible for setting the default gas now retrieves an
up-to-date copy of `txMeta`, and conditionally sets the defaults only
if they haven't yet been set.
This race condition was introduced in #2962, though that PR also added
a loading screen that avoided this issue by preventing the user from
interacting with the transaction until after the gas had been
estimated. Unfortunately this loading screen was not carried forward to
the new UI.
* Remove `estimatedGas` property from `txMeta`
The `estimatedGas` property was a cache of the gas value estimated for
a transaction when the default gas limit was set. This property wasn't
used anywhere. It may have been useful for debugging purposes, but the
same gas estimate is already stored on the `history` property so it
should be present in state logs regardless.
* Remove `gasLimitSpecified` txMeta property
The `gasLimitSpecified` property of `txMeta` wasn't used for anything.
It might have been useful for debugging purposes, but whether or not
the gas limit was specified can also be determined from looking at the
transaction history, so it's not a huge loss.
* Remove `gasPriceSpecified` txMeta property
The `gasPriceSpecified` property of `txMeta` wasn't used for anything.
It might have been useful for debugging purposes, but whether or not
the gas price was specified can also be determined from looking at the
transaction history, so it's not a huge loss.
* Remove `simpleSend` txMeta property
The `simpleSend` property of `txMeta` was used to ensure a buffer was
not added to the gas limit during gas estimation for simple send
transactions. It was made redundant by #8484, which accomplishes this
without the use of this property.
Previously a transaction would get assigned a default value during the
`addTxGasDefaults` function, after the transaction was added and sent
to the UI.
Instead the transaction is assigned a default value before it gets
added. This flow is simpler to follow, and it avoids the race condition
where the transaction is assigned a value from the UI before this
default is set. In that situation, the UI-assigned value would be
overridden, which is obviously not desired.
`analyzeGasUsage` now returns the results of the analysis rather than
setting them directly on `txMeta`. The caller is now responsible for
mutating `txMeta` instead. Functionally this should be identical to
before.
The simple send gas estimation has been moved out of the gas estimation
module, and into the transaction controller. This was done in an effort
to limit the number of places where `txMeta` is mutated while the
default gas parameters are being set.
Backport #8445 to v7.7.9. Original commit description:
* Don't updatePendingTxs outside of block updates
Refs #8377
Reverts 507397f6c (#5431)
* Check for new block data on unlock
Co-authored-by: Whymarrh Whitby <whymarrh.whitby@gmail.com>
Backport #8363 to v7.7.9. Note that this uses `clone` instead of
`cloneDeep`, because `clone` hadn't yet been replaced by `cloneDeep` on
`master`.
Backporting that change as well would have been very disruptive, so
I've updated this to use `clone` instead to minimize conflicts. It is
functionally equivalent.
Co-authored-by: Whymarrh Whitby <whymarrh.whitby@gmail.com>
This backports the deletion of the Dai/Sai migration notification
(#8418). Note that the migration to delete the now unused background
state has not been included, as it is non-essential and would have been
more difficult to backport. The migration to delete the unused state
will be included in the next major release instead.
This is a backport of #8314. Here's the original description:
MetaMask would sometimes get into a state where the notification popup
would never open. This could happen if the notification window was
closed shortly after being opened. After this happened, no popups would
show up until after the extension was reset.
This was happening because the background thought the popup was already
open. The variable it uses to track whether the popup was open or not
was being set to `true` immediately after the background asked the
browser to open a new window, before a handler was attached that could
respond to the window being closed.
Removing this line seems to solve the problem.
This line was added originally in #5437, which dealt with batch
transactions. Batches of transactions seem to work just fine without
this line though (from local testing), and I can't think of why this
would be required.
Closes#7051
ricky
Henrique Dias
Mark Stacey
Erik Marks
Whymarrh Whitby
Dan J Miller
Brad Decker