Adds the latest version of `@metamask/controllers`, and updates our usage of the `ApprovalController`, which has been migrated to `BaseControllerV2`. Of [the new `controllers` release](https://github.com/MetaMask/controllers/releases/tag/v15.0.0), only the `ApprovalController` migration should be breaking.
This is the first time we use events on the `ControllerMessenger` to update the badge, so I turned the messenger into a property on the main `MetaMaskController` in order to subscribe to events on it in `background.js`. I confirmed that the badge does indeed update during local QA.
As it turns out, [MetaMask/controllers#571](https://github.com/MetaMask/controllers/pull/571) was breaking for a single unit test case, which is now handled during setup and teardown for the related test suite (`metamask-controller.test.js`).
There are a few issues encountered when running `yarn setup` on new
Apple Silicon (aka M1, aka arm64) Macs:
* The script halts when attempting to run the install step for
the `chromedriver` package with the message "Only Mac 64 bits
supported". This is somewhat misleading as it seems to indicate that
chromedriver can only be installed on a 64-bit Mac. However, what I
think is happening is that the installation script for `chromedriver`
is not able to detect that an arm64 CPU *is* a 64-bit CPU. After
looking through the `chromedriver` repo, it appears that 87.0.1 is the
first version that adds a proper check ([1]).
Note that upgrading chromedriver caused the Chrome-specific tests to
fail intermittently on CI. I was not able to 100% work out the reason
for this, but ensuring that X (which provides a way for Chrome to run
in a GUI setting from the command line) is available seems to fix
these issues.
* The script also halts when attempting to run the install step for
the `electron` package. This happens because for the version of
`electron` we are using (9.4.2), there is no available binary for
arm64. It appears that Electron 11.x was the first version to support
arm64 Macs ([2]). This is a bit trickier to resolve because we don't
explicitly rely on `electron` — that's brought in by `react-devtools`.
The first version of `react-devtools` that relies on `electron` 11.x
is 4.11.0 ([3]).
[1]: 469dd0a6ee
[2]: https://www.electronjs.org/blog/apple-silicon
[3]: https://github.com/facebook/react/blob/main/packages/react-devtools/CHANGELOG.md#4110-april-9-2021
* EIP-1559 - Provide support for Ledger
* Update ui/selectors/selectors.js
Co-authored-by: Mark Stacey <markjstacey@gmail.com>
* Add shared constants for hw types
* bump eth-ledger-bridge-keyring to v0.7.0
Co-authored-by: David Walsh <davidwalsh83@gmail.com>
Co-authored-by: Mark Stacey <markjstacey@gmail.com>
Co-authored-by: Alex <adonesky@gmail.com>
* Increase warning saliency of qr sync
* Remove duplciate locale entries
* Revise wording per Antonela feedback
* Avoid all caps
Co-authored-by: Erik Marks <25517051+rekmarks@users.noreply.github.com>
Co-authored-by: Erik Marks <25517051+rekmarks@users.noreply.github.com>
* Allow submission of transactions with dapp suggested gas fees, while estimates are loading
* Allow editing of transactions with dapp suggested feeds, while estimates are still loading
* Ensure that advanced gas is always editible inline when gas is loading
* Ensure that insufficient balance error is shown when gas is loading if the user has customized the gas
* Only set gas price insufficient errors if the current network is non-eip-1559, or the txparams actually have a gas price
* Remove unnecessary param
* lint fix
* ensure insufficient balance warning is showing when loading
* Ensure that eip1559 network transactions do not combined eip1559 and non-eip1559 gas fee properties
* Lint fix
* Fix Insufficient number of substitutions for key "swapYourTokenBalance"
* Use an empty string if there is no default symbol
* Add ? after SWAPS_CHAINID_DEFAULT_TOKEN_MAP[chainId]
Brad Decker
ryanml
Alex Donesky
Dan J Miller
MetaMask Bot
Erik Marks
Elliot Winkler
Dan Finlay
Daniel
David Walsh