* bump @metamask/controllers to v15.0.1 and remove AbortController workaround in e2e tests
* remove old abortcontroller polyfill
* bump @metamask/controllers to v15.0.2
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>
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`).
This update includes just configuration updates. There are no
functional changes. The updated config is only used as a fallback in
case the config update fails for some reason.
* add metametrics wrapper
* add history dep
* provide test data and mock react router
* add first confirmaion screen
* figure out a way to mock match.params
* render token approval with data
* fix lockfile
* fix lint
* remove use effect
* lintfix
* add . for src paths
* litfix
* Add knobs to change redux store for confirm-approve component (Storybook) (#11135)
* add knob for domain
* knobify
* remove logs
* remove comment
* lintfix
* fix comments
* add background calls + metriccs event to storybook acctions
* lintfixxxx
This update includes a bug fix that made v9.0.1 incompatible with valid
entries for the `package.json` "repository" field. Specifically, that
field required that the repository be the GitHub repo URL, but the
field is meant to point at the _git_ repo URL (the difference between
the two on GitHub is the `.git` suffix).
Now that that bug as been fixed, we can update the `repository` field
to point at `https://github.com/MetaMask/metamask-extension.git`, which
is what it should be.
The CurrencyRateController has been migrated to the BaseControllerV2
API, which includes various API changes. These changes include:
* The constructor now expects to be passed a
`RestrictedControllerMessenger`.
* State changes are subscribed to via the `ControllerMessenger` now,
rather than via a `subscribe` function.
* The state and configration are passed in as one "options" object,
rather than as two separate parameters
* The polling needs to be started explicitly by calling `start`. It
can be stopped and started on-demand now as well.
* Changing the current currency or native currency will now throw an
error if we fail to update the conversion rate.
The `ComposableObservableStore` has been updated to accomodate these
new types of controllers. The constructor has been updated to use an
options bag pattern as well, to make the addition of the new required
`controllerMessenger` parameter a bit less unweildly.
