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.
The test for receiving ETH from a contract had been clicking on the
first transaction list item, assuming it was pending. This is not
necessarily true; if the pending transaction hadn't yet been rendered,
this could select the first confirmed transaction instead.
The test has been updated to look for the first _pending_ transaction,
rather than just the first transaction.
Note that this likely does not fix the intermittent failure we've been
experiencing. The failure has been observed with this fix in place.
This test would occasionally fail due to a fluke of timing, where a
pending transaction would take slightly longer than expected to
be rendered in the "confirmed transactions" list. This `wait` block
ensures the test will try again until it has confirmed.
The test artifact directory for failed test "verbose reports" was
mistakenly being set to `[browser]/undefined`. This was broken during
the refactor in #7798, when the `driver` parameter was mistakenly left
in after the `verboseReportOnFailure` function was converted to a
method being called on `driver`.
An alert is now shown when the user switches from an account that is
connected to the active tab to an account that is not connected. The
alert prompts the user to dismiss the alert or connect the account
they're switching to.
The "loading" state is handled by disabling the buttons, and the error
state is handled by displaying a generic error message and disabling
the connect button.
The new reducer for this alert has been created with `createSlice` from
the Redux Toolkit. This utility is recommended by the Redux team, and
represents a new style of writing reducers that I hope we will use more
in the future (or at least something similar). `createSlice` constructs
a reducer, actions, and action creators automatically. The reducer is
constructed using their `createReducer` helper, which uses Immer to
allow directly mutating the state in the reducer but exposing these
changes as immutable.
`addToAddressBook` returned a thunk that didn't return a Promise,
despite doing async work. It now returns a Promise.
The callers of this action creator were updated to `await` the
completion of the operation. It was called just before redirecting the
user to a different page or closing a modal, and it seemed appropriate
to wait before doing those things.
The `getSelectedAddress` selector has a fallback of selecting the first
MetaMask account. This is not useful. The only time the
`selectedAddress` is not set is during onboarding, before any accounts
exist, so selecting the first account wouldn't be useful anyway.
Co-authored-by: Erik Marks <25517051+rekmarks@users.noreply.github.com>
`setRpcTarget` returned a thunk that didn't return a Promise, despite
doing async work. It now returns a Promise.
The callers of this action creator didn't need to be updated, as they
were all in event handlers that didn't require knowing when the
operation had completed.
Changes to the background state were being detected in the `update`
event handler in `ui/index.js` that receives state updates from the
background. However this doesn't catch every update; some state
changes are received by the UI in-between these `update` events.
The background `getState` function is callable directly from the UI,
and many action creators call it via `forceUpdateMetamaskState` to
update the `metamask` state immediately without waiting for the next
`update` event. These state updates skip this change detection in
`ui/index.js`.
For example, if a 3Box state restoration resulted in a `currentLocale`
change, and then a `forceUpdateMetamaskState` call completed before the
next `update `event was received, then `updateCurrentLocale` wouldn't
be called, and the `locale` store would not be updated correctly with
the localized messages for the new locale.
We now check for background state changes in the `updateMetamaskState`
action creator. All `metamask` state updates go through this function,
so we aren't missing any changes anymore.
`setProviderType` returned a thunk that didn't return a Promise,
despite doing async work. It now returns a Promise.
None of the callers of this action creator needed to know when it
completed, so no changes to the call sites were made.
A simple default store of `{ metamask: {} }` is now used for the
actions tests.
While I would prefer that any expectations about the store be included
in each test, the mere existence of this `metamask` object seems like
a fairly reasonable default, as it's (hopefully) impossible for it to
be unset at runtime.
The `2-state.json` test state file was deleted as well, as it was no
longer used.
Many of the "message manager" background methods return a full copy of
the background state in their response; presumably to save us from
making a full round-trip to update the UI `metamask` state after it
changes. However, the action creators responsible for calling these
methods were calling `updateMetamaskState` even when the background
method failed. In effect, they were setting the UI `metamask` state to
`undefined`.
They have been updated to only set the UI `metamask` state if the
background method succeeded.
`setSelectedAddress` returned a thunk that didn't return a Promise,
despite doing async work. It now returns a Promise.
This action creator was only called in two places, and neither benefit
from using the Promise now returned. They were both event handlers. In
both cases there was an existing Promise chain, but the only thing
after this set was a `catch` block that displayed any error
encountered. I decided not to return the result of `setSelectedAddress`
to this chain, because all it would do is set the warning a second
time in the event of failure.
`showAccountDetail` returned a thunk that didn't return a Promise,
despite doing async work. Now it returns a Promise.
This action is only called in one place, and it looks like the actions
dispatched alongside it were meant to be run in parallel, so no changes
were made there.
The `shift-list-item` component for displaying ShapeShift transactions
has been removed, along with three other components that were used
solely by that component (`copyButton`, `eth-balance`, and
`fiat-value`).
This component hasn't been used in some time, as ShapeShift
transactions no longer exist to display. The controller that ShapeShift
transactions originated from was removed in #8118, and it became
impossible to create new ShapeShift transactions from within MetaMask
in #6746
This state has been removed from the background. It was used for the
old UI, and has been unused for some time. A migration has been added
to delete this state as well.
The action creator responsible for updating this state has been removed
from the UI as well, along with the `callBackgroundThenUpdateNoSpinner`
convenience function, which was only used for this action.
The `transForward` app state is no longer used, so it has been removed.
Associated actions have been removed as well.
This state dates back a few years, so I was unable to determine when it
was made obsolete.
Keyrings are added either through the `getKeyringForDevice` background
method (as part of the hardware wallet connect flow), or via
`importAccountWithStrategy` (when importing an account). The
`addNewKeyring` action and corresponding background method has not been
used in a long time.
This state hasn't been used since #5886. The nonce we display in our UI
is now from the background, rather than queried directly from the
front-end.
This also means we save making this network call each time a pending
transaction is added, and each time the transaction list is mounted.
Some of the unit tests for `actions.js` were calling async actions
without `await`-ing them. All async actions are now called with `await`
to ensure they've completed.
`markPasswordForgotten` is an asynchronous function, but it was being
called synchronously. The page was redirected without waiting for the
operation to complete.
We now wait for the operation to complete before continuing. Failure is
still not being handled correctly, but that will be addressed in a
separate PR.
* Add popover for informing user about the connected status indicator
* Ensure user only sees connected status info popover once
* Default connectedStatusPopoverHasBeenShown to true and set it to false in a migration
* Add unit test for migration 42
* Initialize AppStateController if it does not exist in migration 42
* Update connect indicator popup locale text
* Code cleanup for connected-indicator-info-popup
* Code cleanup for connected-indicator-info-popup
This method adds the given account to the given origin's list of
exposed accounts. This method is not yet used, but it will be in
subsequent PRs (e.g. #8312)
This method has been added to the background API, and a wrapper action
creator has been written as well.
Now that identities are available synchronously in the permissions
controller, accounts can be validated synchronously as well. Any
account the user wants to give permissions to should already be tracked
as an identity in the preferences controller.
* Fix order of accounts in `eth_accounts` response
The accounts returned by `eth_accounts` were in a fixed order - the
order in which the keyring returned them - rather than ordered with the
selected account first. The accounts returned by the `accountsChanged`
event were ordered with the selected account first, but the same order
wasn't used for `eth_accounts`.
We needed to store additional state in order to determine the correct
account order correctly on all dapps. We had only been storing the
current selected account, but since we also need to determine the
primary account per dapp (i.e. the last "selected" account among the
accounts exposed to that dapp), that wasn't enough.
A `lastSelected` property has been added to each identity in the
preferences controller to keep track of the last selected time. This
property is set to the current time (in milliseconds) whenever a new
selection is made. The accounts returned with `accountsChanged` and by
`eth_accounts` are both ordered by this property.
The `updatePermittedAccounts` function was merged with the internal
methods for responding to account selection, to keep things simpler. It
wasn't called externally anyway, so it wasn't needed in the public API.
* Remove caveat update upon change in selected account
The order of accounts in the caveat isn't meaningful, so the caveat
doesn't need to be updated when the accounts get re-ordered.
* Emit event regardless of account order
Now that we're no longer relying upon the caveat for the account order,
we also have no way of knowing if a particular account selection
resulted in a change in order or not. The notification is now emitted
whenever an exposed account is selected - even if the order stayed the
same.
The inpage provider currently caches the account order, so it can be
relied upon to ignore these redundant events. We were already emiting
redundant `accountsChanged` events in some cases anyway.
Selecting a new account now results in all domains that can view this
change being notified. Previously only the dapp in the active tab was
being notified (though not correctly, as the `origin` was accidentally
set to the MetaMask chrome extension origin).
This handling of account selection has been moved into the background
to minimize the gap between account selection and the notification
being sent out. It's simpler for the UI to not be involved anyway.
Previously all browser globals were allowed to be used anywhere by
ESLint because we had set the `env` property to `browser` in the ESLint
config. This has made it easy to accidentally use browser globals
(e.g. #8338), so it has been removed. Instead we now have a short list
of allowed globals.
All browser globals are now accessed as properties on `window`.
Unfortunately this change resulted in a few different confusing unit
test errors, as some of our unit tests setup assumed that a particular
global would be used via `window` or `global`. In particular,
`window.fetch` didn't work correctly because it wasn't patched by the
AbortController polyfill (only `global.fetch` was being patched).
The `jsdom-global` package we were using complicated matters by setting
all of the JSDOM `window` properties directly on `global`, overwriting
the `AbortController` for example.
The `helpers.js` test setup module has been simplified somewhat by
removing `jsdom-global` and constructing the JSDOM instance manually.
The JSDOM window is set on `window`, and a few properties are set on
`global` as well as needed by various dependencies. `node-fetch` and
the AbortController polyfill/patch now work as expected as well,
though `fetch` is only available on `window` now.
The tests for the detect-tokens controller were nearly all broken. They
have been fixed, and a few improvements were made to controller itself
to help with this.
* The core `detectNewTokens` method has been updated to be async, so
that the caller can know when the operation had completed.
* The part of the function that used `Web3` to check the token balances
has been split into a separate function, so that that part could be
stubbed out in tests. Eventually we should test this using `ganache`
instead, but this was an easier first step.
* The internal `tokenAddresses` array is now initialized on
construction, rather than upon the first Preferences controller update.
The `detectNewTokens` function would have previously failed if it ran
prior to this initialization, so it was failing if called before any
preferences state changes.
Additionally, the `detectTokenBalance` function was removed, as it was
no longer used.
The tests have been updated to ensure they're actually testing the
behavior they purport to be testing. I've simulated a test failure with
each one to check that it'd fail when it should. The preferences
controller instance was updated to set addresses correctly as well.
The "global" action constants (the ones previously in `actions.js`)
have been moved to a separate module. This was necessary to avoid a
circular dependency in an upcoming change that was causing problems.
In general the "ducks" pattern of organizing Redux stores does result
in circular dependency problems. This is because reuse of actions
between reducers is encouraged, so it's not uncommon for two reducers
to want to reference an action from the other. Going forward we can
avoid this problem by moving action constants that are shared between
reducers into this shared module.
This action was never triggered in practice, as MetaMask is never
unlocked from the UI. The unlock always occurs as a result of a
background state update.
* Connect screen popup redesign
* Open permission request in notification instead of tab
* Remove no longer user locales
* Update permissions unit test mock to accout for change of opts passed to permissions controller
* Lint fix
* Inline broken line svg in permission-page-container-content.component.js for faster loading
* Add back button to second screen on connect flow
* Add xOfY locale and use for the page count in the connect flow
* Lint fix for svgs permission-page-container-content.component.js
* Fix rebase error
* Lint fix
* Clean up styles on the connect-screen-into-popup branch
* Use closeCurrentWindow to close window on cancel when in full screen connect flow
* Handle errors in rejectPermissionsRequest
* Full screen styles for connect flow
* Lint fixed in permissions-connect and actions.js
* Redirect screen now shows metamask icon instead of users identicon
* Fix subtitle spacing in permissions-connect-header'
* Use window.close instead of closeCurrentWindow() in cancelPermissionsRequest
* Use permissions-connect-header__subtitle in permissions-connect-header.component
* Add UI for selecting multiple accounts on the first permissions connect screen
* Make accounts list scrollable on connect screen
* Change title wording on connect screen to 'select your accounts'
* Add select all tooltip to info circle on top of connect screen account list
* Add security info footer to the first screen of the connect flow
* Apply redesigns to page 2 of connect flow
* Display number of accounts on connect flow second screen if there are multiple to connect
* Update e2e tests for connect screen multi-select changes
* Remove unused chooseAnAcount message
* Fix styling/display of redirect elements on second page of connect flow
* Assorted small fixes in permissions connect
* Remove unnecessary tiny delays in spec files
* Remove incorrect use of bem modified in choose-account
* Remove unused locale
* Use Set for managing selected accounts in choose-acount and permissions-connect componets
* Compone!
* Move connect flow header into a reusable component, and implement new header designs
* Update locales and add missing locales
* Improve permission list item design (second screen of connect flow)
* Check box component improvements
* Fixes in variables.scss
* Simplfy code in selectAll of choose-account.component
* Hide checkboxes on first pages on connect flow when there is only one account
* Allow autofill of default new account modal text with right arrow
* Disable next button on first screen of connect flow when no accounts selected
* Improve choose-account/index.scss
* Remove metamask secure graphic
* Fix connect flow redirect screen
* Fix connectToMultiple locale
* Remove locales no longer used after connect flow multiple connect updates
* Fix size of dapp icon on redirect screen of connect flow
* Clean up choose-account code
* Stop using placeholder in new-account-modal
* Remove unused styles in permission-page-container/index.scss
* Pass origin instead of site name to PermissionsConnectHeader in connect flow
* Make iconName a required prop in permissions-connect-header
* Show checkbox in cases where there is one account in the choose-account list
* Do not render select all checkbox when only 1 list item, instead of just hiding it
* Small cleanup in choose-account/index.scss
Two tabs have been created on the home screen: 'Assets' and 'History'.
This tabbed view is shown only on small screens (e.g. in the popup).
The fullscreen view is unchanged.
The toggle-able left sidebar no longer exists, so some 'sidebar-left'
specific code and styles have been removed. The button in the menu bar
has been removed as well.
The 'History' title of the transaction history is now redundant when
where are no pending transactions, so it as been conditionally hidden.
A passthrough for `data-testid` has been added to the Tab component for
convenience in e2e tests.
The 'Add Token' component has been redesigned to be more in-line with
the new home screen design. The description instructing the user to
click the 'Add Token' button has been removed, and the section itself
has been made roughly the same size as one of the list item. The text
now appears on just one line, overflowing to two if necessary.
The styles for the TokenCell component have been moved to be alongside
the component. They have also been renamed from `token-list-item` to
match the component name.
This commit updates the existing _Connected Sites_ section to a modal using
the `Popover` component. This will serve as a base for the new modal design.
The `network` prop was being passed to the Identicon despite that not
being an Identicon prop, and the `userAddress` prop was being passed
down by the container but was unused. The methods removed were not
called anywhere.
These two functions were not especially useful. `tOrDefault` was used
only by `tOrKey`, and `tOrKey` was only used in one place. All it did
was return the given `key` directly if it was falsey, so it was easily
replaced by a condition.
The `metamask.send.from` field was assumed by various selectors to be
an object, but instead it was recently set to a string. The selectors
have been updated to assume it's a string, and to fetch the full
account object explicitly.
The selector `getSendFromObject` was repurposed for this, as that's
basically what it already did. The optional address parameter was
removed though, as that was only used to fetch the `from` address in
cases where the `send` state was set without there being a `from`
address set. That case is no longer possible, as the `from` address is
always set upon the initialization of the `send` state.
The `getSendFromObject` selector no longer fetches the 'name' of that
address from the address book state either. This property was not used
in either of the cases this selector was used.
The "Transaction View" component has been merged with the Home
component. The division between these two components seemed wrong
because the "Transaction View" contained the menu bar (distinctly a
"home" thing, not a "transaction" thing), and we will be adding more
non-transaction-related components shortly.
This also let us use a single `Media` component instead of two.
The `tabId` of the message sender is now added to the middleware
request object. This step is omitted if the `tabId` is not provided.
This is done early in the middleware stack, so the `tabId` should be
available for any subsequent middleware to use.
The Onboarding Middleware has also been modified to get the `tabId`
from the request object, rather than expecting it as a parameter upon
creation.
This refactor will enable further uses of the `tabId`.
Implement `eth_decrypt` and `eth_getEncryptionPublicKey`. This allows decryption backed by the user's private key. The message decryption uses a confirmation flow similar to the messaging signing flow, where the message to be decrypted is also able to be decrypted inline for the user to read directly before confirming.
* Revert "Revert "Update Wyre ETH purchase url" (#7631)"
This reverts commit bc67d1eeca.
* Restrict widget to just debit card payments
Apple Pay apparently only works on Safari.
* Use @metamask/eslint-config@1.1.0
* Use eslint-plugin-mocha@6.2.2
* Mark root ESLint config as root
* Update Mocha ESLint rules with shared ESLint config
* Various component tests and some conditional statements
Conditional in account-menu in removeAccount when keyring sometimes is not initially provideed
Conditional on unlock-page when there is no target.getBoundingClientRect on the element.
* Update helpers
* Remove component debugging
* Add default params for render helpers
* Remove stubComponent for old Mascot
Changes in https://github.com/MetaMask/metamask-extension/pull/7893 has prevented the need to stub it out.
Change logout to lock in account-menu test
This was done to reduce the number of direct dependencies we have. It
should be functionally equivalent. The bundle size should not change,
as we use `clone` as a transitive dependency in a number of places.
Unhandled rejections are now caught using built-in Node.js APIs instead
of with `bluebird`. `bluebird` was added as a production dependency but
was only used for this purpose. The code responsible for catching
unhandled rejection in the browser was removed, as this test helper is
never run in the browser.
Additionally, unhandled rejections are tracked over the course of all
tests, and result in a non-zero exit code if they remain at the end.
This was done because it is possible for errors to trigger the
`uncaughtRejection` event but then still be handled later on. This is
uncommon, and doesn't seem to happen in our test suite. But if it does
in the future, it'll be logged but won't result in a non-zero exit
code.
