When the NetworkController in this repo was replaced with
`@metamask/network-controller`, support for Linea networks was lost
as it did not support it at that time. `@metamask/network-controller`
has since been updated, so this commit bumps that package to restore
support.
* bump parse5; port patch
* devDeps: jsdom@11.5.1->16.7.0
- patch-revert https://github.com/jsdom/jsdom/pull/2076
- jsdom's storage-overriding does not play well with test suite usage of
localforage:
$ yarn test:unit:global
✖ ERROR: TypeError: Cannot set property localStorage of #<Window> which has only a getter
at Object.<anonymous> (/app/test/helpers/setup-helper.js:79:32)
at Module._compile (node:internal/modules/cjs/loader:1198:14)
at Module.m._compile (/app/node_modules/ts-node/src/index.ts:1459:23)
at Module._compile (/app/node_modules/pirates/lib/index.js:136:24)
at Module._extensions..js (node:internal/modules/cjs/loader:1252:10)
at newLoader (/app/node_modules/pirates/lib/index.js:141:7)
at Object.require.extensions.<computed> [as .js] (/app/node_modules/ts-node/src/index.ts:1462:12)
at Module.load (node:internal/modules/cjs/loader:1076:32)
at Function.Module._load (node:internal/modules/cjs/loader:911:12)
at Module.require (node:internal/modules/cjs/loader:1100:19)
at require (node:internal/modules/cjs/helpers:108:18)
at Object.<anonymous> (/app/test/setup.js:4:1)
at Module._compile (node:internal/modules/cjs/loader:1198:14)
at Object.Module._extensions..js (node:internal/modules/cjs/loader:1252:10)
at Module.load (node:internal/modules/cjs/loader:1076:32)
at Function.Module._load (node:internal/modules/cjs/loader:911:12)
at ModuleWrap.<anonymous> (node:internal/modules/esm/translators:169:29)
at ModuleJob.run (node:internal/modules/esm/module_job:193:25)
at async Promise.all (index 0)
at ESMLoader.import (node:internal/modules/esm/loader:530:24)
at importModuleDynamicallyWrapper (node:internal/vm/module:438:15)
at formattedImport (/app/node_modules/mocha/lib/nodejs/esm-utils.js:7:14)
at exports.requireOrImport (/app/node_modules/mocha/lib/nodejs/esm-utils.js:48:32)
at exports.handleRequires (/app/node_modules/mocha/lib/cli/run-helpers.js:94:28)
at /app/node_modules/mocha/lib/cli/run.js:353:25
* update lavamoat policies
* update lavamoat build policy
* Sending showCustodyConfirmLink as a prop and fixing other issues
* Upgraded MMI extension monrepo and trying to fix the issue
* prevents deeplink from closing
* Fixed styles of Custody view and changed the place of it
* Fixed CI issues
* fixing eslint issues
* Update LavaMoat policies
* fixing tests
* Fixed test
* updated snapshots
* reorder, otherwise it won't make sense
* adds necessary methods
* removes duplicated key value
* updated snapshot
---------
Co-authored-by: Antonio Regadas <antonio.regadas@consensys.net>
Co-authored-by: MetaMask Bot <metamaskbot@users.noreply.github.com>
Co-authored-by: António Regadas <apregadas@gmail.com>
* Prevent controller events from crashing
The package `@metamask/base-controller` has been updated to v3.1, which
includes a change to how event subscriber errors are handled. Errors
thrown in event subscribers will no longer interrupt event publishing.
Subscriber errors are caught and thrown in a timeout handler, ensuring
that they are logged and captured by Sentry. We can find any subscriber
errors by looking at the background console, or at the Sentry
dashboard.
Fixes#19801
* Update LavaMoat policies
---------
Co-authored-by: MetaMask Bot <metamaskbot@users.noreply.github.com>
* Prevent controller events from crashing
The package `@metamask/base-controller` has been updated to v3.1, which
includes a change to how event subscriber errors are handled. Errors
thrown in event subscribers will no longer interrupt event publishing.
Subscriber errors are caught and thrown in a timeout handler, ensuring
that they are logged and captured by Sentry. We can find any subscriber
errors by looking at the background console, or at the Sentry
dashboard.
Fixes#19801
* Update LavaMoat policies
---------
Co-authored-by: MetaMask Bot <metamaskbot@users.noreply.github.com>
Preview builds were setup to install correctly on CircleCI prior to
the Yarn v3 upgrade, but that integration broke with that upgrade. The
Yarn and CircleCI configuration has been updated to fix this.
The `.yarnrc.yaml` file has been updated to configure the GitHub
registry but leave it disabled by default. It can be enabled
dynamically using an environment variable. This lets us switch between
registries without updating the file.
The new workflow is documented here: https://github.com/MetaMask/core/pull/1481
The `--frozen-lockfile` flag is not supported by Yarn v3. It has been
replaced by the Yarn v3 equivalent, which is `--immutable`.
Additionally, the `deps-install` script was deleted and this command
was inlined in the CircleCI configuration. I don't think we need to
maintain a separate script just for one command.
The command `yarn lavamoat:auto` will fail unless the environment
variable `CONFIGURATION_SERVICE_URL` is set locally. Most contributors
will have no reason to set this to anything.
This has been fixed by assigning this variable a default value of an
empty string, as the error suggests doing.
Occasionally our builds have been failing with the error "Unexpected
end of JSON input", with a stack pointing at `lavamoat-core`. The file
in question was reading the policy, reading overrides, merging them,
then writing the policy back to disk.
The intermittent errors can be explained if the policy file was read in
one process while it was being written in another. The extension build
script builds bundles in multiple processes in parallel, so it does
follow that this would happen some of the time. This could result in a
partial policy file being read by the build script, resulting in a JSON
parsing error.
This has been fixed by removing the policy write step using a patch.
We don't need this step. We update the policy using a different
function altogether, and we have a CI job to ensure we never forget to
update it.
The e2e test script now accepts a `--retry-until-failure` flag that can
be useful for locally reproducing intermittent failures.
Normally the `retries` option will only retry upon failure. But if
you want the test to fail to inspect the failure state, you want it to
keep running until the first failure then stop. This flag accomplishes
that, reversing the retry conditions.
Our e2e test driver was building the locator object multiple times over
in some cases. The `Locator` object is required by certain webdriver
methods, but our driver methods all accept a "raw locator".
This change avoids a few redundant calls, and makes it easier to
improve the error message for a timeout failure (which will be done in
a later PR). It also makes the code match the documentation/parameter
names.
The default network controller state is currently invalid on test
builds. The initial state is set to localhost (Ganache) on test builds,
but that network configuration is missing.
The initial state for test builds has been updated to include the
network configuration for localhost. Additionally, the initial state
was updated to only be applied if persisted state is missing. This is
to ensure the initial network configuration state doesn't override test
fixtures in e2e tests.
The legacy gas API is still useful for BSC, which is a network our APIs
support that is not EIP-1559 compatible. The legacy gas API will now be
used for BSC prior to using RPC methods as a fallback.
This brings extension closer in alignment with mobile, which also uses
the legacy gas API for BSC.
The E2E network mock function has been updated to use a variable for
the initial test network. This made it easier to write the e2e test for
the BSC case.
Two new security advisories have been resolved. These advisories are
causing CI to fail on `develop`. Neither presents any risk to us,
as they are prototype pollution issues that are prevented by lockdown.
The first advisory isn't easy for us to patch. It's caused by an
outdated version of `protobufjs` used by `@trezor/transport`. It has
been ignored for now, until Trezor updates that package.
For the second advisory (related to `tough-cookie`), it was resolved
by updating that dependency in our lockfile.
