* Version v10.18.4
* Fix default currency symbol for `wallet_addEthereumChain` + improve warnings for data that doesn't match our validation expectations (#15201)
* set more appropriate default for ticker symbol when wallet_addEthereumChain is called
* throw error to dapp when site suggests network with same chainId but different ticker symbol from already added network, instead of showing error and disabled notification to user
* Fix Provider Tracking Metrics (#15082)
* fix filetype audit (#15334)
* Remove decentralized 4byte function signature registry since it contains incorrect signatures and we can't algorithmically check for best option when 4byte.directory is down (#15300)
* remove decentralized 4byte function signature registry since it is griefed and we can't algorithmically check for best option when 4byte is down
* add migration
* remove nock of on chain registry call in getMethodDataAsync test
* remove audit exclusion (#15346)
* Updates `eth-lattice-keyring` to v0.10.0 (#15261)
This is mainly associated with an update in GridPlus SDK and enables
better strategies for fetching calldata decoder data.
`eth-lattice-keyring` changes:
GridPlus/eth-lattice-keyring@v0.7.3...v0.10.0
`gridplus-sdk` changes (which includes a codebase rewrite):
GridPlus/gridplus-sdk@v1.2.3...v2.2.2
* Fix 'block link explorer on custom networks' (#13870)
* Created a logic for the 'Add a block explorer URL'
Removed unused message
Message logic rollback
Modified history push operation
WIP: Pushing before rebasing
Applied requested changes
Removed unintenionally added code
* Lint fix
* Metrics fixed
* Stop injecting provider on docs.google.com (#15459)
* Fix setting of gasPrice when on non-eip 1559 networks (#15628)
* Fix setting of gasPrice when on non-eip 1559 networks
* Fix unit tests
* Fix logic
* Update ui/ducks/send/send.test.js
Co-authored-by: Mark Stacey <markjstacey@gmail.com>
Co-authored-by: Mark Stacey <markjstacey@gmail.com>
* [GridPlus] Bumps `eth-lattice-keyring` to v0.11.0 (#15490)
* [GridPlus] Bumps `gridplus-sdk` to v2.2.4 (#15561)
* remove exclusions for mismatched object jsdoc type casing (#15351)
* Improve `tokenId` parsing and clean up `useAssetDetails` hook (#15304)
* Fix state creation in setupSentryGetStateGlobal (#15635)
* filter breadcrumbs for improved clarity while debugging sentry errors (#15639)
* Update v10.18.4 changelog (#15645)
* Auto generated changelog
* Update 10.18.4 changelog
* Run lavamoat:auto
* Call metrics event for wallet type selection at the right time (#15591)
* Fix Sentry in LavaMoat contexts (#15672)
Our Sentry setup relies upon application state, but it wasn't able to
access it in LavaMoat builds because it's running in a separate
Compartment.
A patch has been introduced to the LavaMoat runtime to allow the root
Compartment to mutate the `rootGlobals` object, which is accessible
from outside the compartment as well. This lets us expose application
state to our Sentry integration.
* Fix Sentry deduplication of events that were never sent (#15677)
The Sentry `Dedupe` integration has been filtering out our events, even
when they were never sent due to our `beforeSend` handler. It was
wrongly identifying them as duplicates because it has no knowledge of
`beforeSend` or whether they were actually sent or not.
To resolve this, the filtering we were doing in `beforeSend` has been
moved to a Sentry integration. This integration is installed ahead of
the `Dedupe` integration, so `Dedupe` should never find out about any
events that we filter out, and thus will never consider them as sent
when they were not.
* Replace `lavamoat-runtime.js` patch (#15682)
A patch made in #15672 was found to be unnecessary. Instead of setting
a `rootGlobals` object upon construction of the root compartment, we
are now creating a `sentryHooks` object in the initial top-level
compartment. I hadn't realized at the time that the root compartment
would inherit all properties of the initial compartment `globalThis`.
This accomplishes the same goals as #15672 except without needing a
patch.
* Update v10.18.4 changelog
* Fix lint issues
* Update yarn.lock
* Update `depcheck` to latest version (#15690)
`depcheck` has been updated to the latest version. This version pins
`@babel/parser` to v7.16.4 because of unresolved bugs in v7.16.5 that
result in `depcheck` failing to parse TypeScript files correctly.
We had a Yarn resolution in place to ensure `@babel/parser@7.16.4` was
being used already. That resolution is no longer needed so it has been
removed. This should resove the issue the dev team has been seeing
lately where `yarn` and `yarn-deduplicate` disagree about the state the
lockfile should be in.
* Update yarn.lock
* Update LavaMoat policy
* deduplicate
* Update LavaMoat build policy
Co-authored-by: MetaMask Bot <metamaskbot@users.noreply.github.com>
Co-authored-by: Alex Donesky <adonesky@gmail.com>
Co-authored-by: Brad Decker <bhdecker84@gmail.com>
Co-authored-by: Alex Miller <asmiller1989@gmail.com>
Co-authored-by: Filip Sekulic <filip.sekulic@consensys.net>
Co-authored-by: Erik Marks <25517051+rekmarks@users.noreply.github.com>
Co-authored-by: Dan J Miller <danjm.com@gmail.com>
Co-authored-by: Mark Stacey <markjstacey@gmail.com>
Co-authored-by: seaona <54408225+seaona@users.noreply.github.com>
Co-authored-by: seaona <mariona@gmx.es>
Co-authored-by: PeterYinusa <peter.yinusa@consensys.net>
ESLint rules have been added to enforce our JSDoc conventions. These
rules were introduced by updating `@metamask/eslint-config` to v9.
Some of the rules have been disabled because the effort to fix all lint
errors was too high. It might be easiest to enable these rules one
directory at a time, or one rule at a time.
Most of the changes in this PR were a result of running
`yarn lint:fix`. There were a handful of manual changes that seemed
obvious and simple to make. Anything beyond that and the rule was left
disabled.
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
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
The benchmark script can now be set to retry upon failure, like the E2E
tests do. The default is zero, just as with the E2E tests. A retry of 2
has been set in CI to match the E2E tests as well.
The `retry` module had to be adjusted to throw an error in the case of
failure. Previously it just set the exit code, but that only worked
because it was the last thing called before the process ended. That is
no longer the case.
This script makes it easier to run an individual E2E test. In the past
I've run individual scripts by editing `run-all.sh` manually, but now
that can be done more easily with this script. It also allows setting
the number of retries to use and the browser to use from the CLI.
This script has been added as an npm script as well, called
'test:e2e:single'.
The `run-all.sh` script was rewritten in JavaScript to make it easier
to pass through a `--retries` argument.
The default number of retries has been set to zero to make local
testing easier. It has been set to 2 on CI.
This was mainly done to consolidate the code used to run an E2E test in
one place, to make later improvements easier.
MetaMask Bot
Brad Decker
Mark Stacey
Elliot Winkler