* create custom addHexPrefix function
* switch to custom addHexPrefix
Co-authored-by: Mark Stacey <markjstacey@gmail.com>
Co-authored-by: Erik Marks <rekmarks@protonmail.com>
Adds swaps-gas-customization-modal and utilize in swaps
Remove swaps specific code from gas-modal-page-container/
Remove slow estimate data from swaps-gas-customization-modal.container
Use average as lower safe price limit in swaps-gas-customization-modal
Lint fix
Fix up unit tests
Update ui/app/ducks/swaps/swaps.js
Co-authored-by: Mark Stacey <markjstacey@gmail.com>
Remove stale properties from gas-modal-page-container.component.js
Replace use of isCustomPrice safe with isCustomSwapsGasPriceSafe, in swaps-gas-customization-modal
Remove use of averageIsSafe in isCustomPriceSafe function
Stop calling resetCustomGasState in swaps
Refactor 'setter' type actions and creators to 'event based', for swaps slice custom gas logic
Replace use of advanced-tab-content.component with advanceGasInputs in swaps gas customization component
Add validation for the gasPrices endpoint
swaps custom gas price should be considered safe if >= to average
Update renderDataSummary unit test
Lint fix
Remove customOnHideOpts for swapsGasCustomizationModal in modal.js
Better handling for swaps gas price loading and failure states
Improve semantics: isCustomSwapsGasPriceSafe renamed to isCustomSwapsGasPriceUnSafe
Mutate state directly in swaps gas slice reducer
Remove unused params
More reliable tracking of speed setting for Gas Fees Changed metrics event
Lint fix
Throw error when fetchSwapsGasPrices response is invalid
add disableSave and customTotalSupplement to swaps-gas-customization container return
Update ui/app/ducks/swaps/swaps.js
Co-authored-by: Mark Stacey <markjstacey@gmail.com>
Improve error handling in fetchMetaSwapsGasPriceEstimates
Remove metricsEvent from swaps-gas-customization-modal context
Base check of gas speed type in swaps-gas-customization-modal on gasEstimateType
Improve naming of variable and functions use to set customPriceIsSafe prop of AdvancedGasInputs in swaps-gas-customization-modal
Simplify sinon spy/stub code in gas-price-button-group-component.test.js
Remove unnecessary getSwapsFallbackGasPrice call in swaps-gas-customization-modal
Remove use of getSwapsTradeTxParams and clean up related gas price logic in swaps
Improve validator of SWAP_GAS_PRICE_VALIDATOR
Ensure default tradeValue
* Delete CachedBalancesController.cachedBalances
* Migrate provider to Rinkeby instead of deleting it
* Convert hex transaction metamaskNetworkId values to decimal
* Don't migrate provider state in e2e tests
* Don't kick custom RPC users to Rinkeby unnecessarily
* Use provider.chainId for address book chainId values
* Add address book migration
* Fix failing unit test
* fixup! Merge branch 'develop' into address-book-use-chainId
* Select address book entries for display by chainId
* Merge all address book entry keys
* fixup! Merge all address book entry keys
* Stop passing a gas param to the estimateGas call initiated in the swaps controller timedoutGasReturn
* Stop passing gas params to timedoutGasReturn
* Lint fix
* Stop passing no longer used param to setInitialGasEstimate
* Use verifyPassword instead of submitPassword when exporting priv key
Fixes#9287 which was when submitPassword is called will fully clear the keyring state
https://github.com/MetaMask/KeyringController/blob/master/index.js#L155ad823d0ac1/index.js (L562)ad823d0ac1/index.js (L726)
Also, pass hideWarning action prop so it will clear the appState.warning if a correct password is never provided on componentWillUnmount
* Hide Warning on componentWillUnmount
* Update exportAccount tests to verifyPassword
* Update ui/app/store/actions.js
Co-authored-by: Mark Stacey <markjstacey@gmail.com>
* Clear Account Details in AppState
We store sensitive information in the AppState under accountDetail for when the modal is active and present. This adds a new action/reducer and componentWillUnmount to clean up the persisted data left after leaving the modal.
* Remove reduntant clearAccountDetails call when clicking done button
The loading indication had remained after successfully signing with
`personal_sign`. This mistake was introduced accidentally in #8434.
This is noticeable if you confirm the signature in the popup UI or
fullscreen UI, as they remain open after signing. The notification UI
closes after signing without waiting for this loading indicator to be
removed.
We were including the polyfill for the `Intl.RelativeTimeFormat` API,
but we weren't including any locale data. This polyfill doesn't work
without the locale data for whichever locale you're formatting.
The data for all locales we support is now included. The locale data
is loaded from disk as-needed (during app startup, and upon each change
in locale).
There was a case where the `activeTab.origin` was not set, yet the user
could still navigate to the "Connected accounts" modal, which assumes
that `activeTab.origin` is set. This would happen in Firefox when the
user opened the popup on a page internal to Firefox (e.g.
`about:blank`). The connected status indicator would still be shown,
but the UI would crash when it was clicked.
The connected status indicator is now hidden whenever
`activeTab.origin` is falsy. The 'Unconnected account' alert has also
been made impossible to trigger in that circumstance.
Fixes#8835
In cases where the registry failed to load, and the sig is set to `{}` on this line: e85b162651/ui/app/helpers/utils/transactions.util.js (L78) this proceeds to set the method prefix to `{}` in knownMethodData.
Additionally check if the method prefix object is empty to proceed call getMethodDataAsync again.
I could only reproduce by intentionally failing the method registry lookup and found this solution. I could not find an instance where the registry consistently failed to lookup even on slow/throttled/high latency networks.
* update connected accounts appearance
* consolidate account alerts
* UnconnectedAccountAlert: use ConnectedAccountsList
* move switch account action out of menu in all views
Co-authored-by: Mark Stacey <markjstacey@gmail.com>
A new page has been created for viewing assets. This replaces the old
`selectedToken` state, which previously would augment the home page
to show token-specific information.
The new asset page shows the standard token overview as seen previously
on the home page, plus a history filtered to show just transactions
relevant to that token.
The actions that were available in the old token list menu have been
moved to a "Token Options" menu that mirrors the "Account Options"
menu.
The `selectedTokenAddress` state has been removed, as it is no longer
being used for anything.
`getMetaMetricState` has been renamed to `getBackgroundMetaMetricState`
because its sole purpose is extracting data from the background state
to send metrics from the background. It's not really a selector, but
it was convenient for it to use the same selectors the UI uses to
extract background data, so I left it there for now.
A new Redux store has been added to track state related to browser history.
The most recent "overview" page (i.e. the home page or the asset page) is
currently being tracked, so that actions taken from the asset page can return
the user back to the asset page when the action has finished.
The chosen token in the `send` flow was set from one of two places:
`metamask.selectedTokenAddress` or `metamask.send.token`. The former is
used most of the time, but the latter is used for the 'Edit' button
shown in the upper-left of the confirmation UI.
The send flow will now exclusively use `metamask.send.token` for the
token state during the send flow. `metamask.selectedTokenAddress` is
now only used for the selected token state on the Home screen. This
simplifies the Redux state, as the send token is now in one place
instead of two, and `metamask.selectedTokenAddress` has only one
purpose.
The `decimals` property of tokens was being set as a string instead of
a Number for any tokens added via `getTokenParams`. It's now cast to a
Number instead.
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.
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.
Tokens are now updated when the account switches after a failed account
import. The usual account switching flow (via the account menu) already
updated tokens, but this step was omitted when the account switched
after a failed import.
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.
`removeFromAddressBook` returned a thunk that didn't return a Promise,
despite doing async work. It now returns a Promise.
The callers were updated to `await` the completion of this operation.
`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.
`editRpc` returned a thunk that didn't return a Promise, despite doing
async work. It now returns a Promise.
In the one place where this is used, it didn't seem important to update
the callsite to block on this finishing. Only one call followed it in
the event handler, and it didn't seem to depend on this.
`updateAndSetCustomRpc` returned a thunk that didn't return a Promise,
despite doing async work. It now returns a Promise.
In the one place where this is used, it didn't seem important to update
the callsite to block on this finishing. Only one call followed it in
the event handler, and it didn't seem to depend on this.
`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.
`editRpc` returned a thunk that didn't return a Promise, despite doing
async work. It now returns a Promise.
In the one place where this is used, it didn't seem important to update
the callsite to block on this finishing. Only one call followed it in
the event handler, and it didn't seem to depend on this.
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.
