* fix: refactor linea goerli testnet implementation
* fix: rename linea goerli network
* feat: add linea testnet logo
* update linea goerli block explorer url
* update @metamask/eth-json-rpc-infura package to version 8.1.0
* fix: refactor ticker map object in shared/constants/networks.ts files
* Update message manager and signature controller
The packages `@metamask/message-manager` and
`@metamask/signature-controller` have been updated to the latest
versions. These versions were part of part of the [core monorepo v53](MetaMask/core#1385)
release. The remaining packages released as part of v53 will be updated
in later PRs.
These releases included a few breaking changes, but none that affect
the extension. Both packages now expect `getCurrentChainId` to return
`Hex`, but that was already the case here. Additionally the signature
controller now has a peer dependency on the approval controller v3,
which is already present and at the correct version.
Relates to #19271
* Ignore error caused by TS bug
* Update types to omit metadata for encryption requests
* Update lavamoat policy
* Update `@metamask/gas-fee-controller` to v6
The `@metamask/address-book-controller` package has been updated to v3.
This version was part of the [core monorepo v53](MetaMask/core#1385)
release. The remaining packages released as part of v53 will be updated
in later PRs.
This release included a number of breaking changes, but most of them
do not affect the extension:
* Bump to Node 16
* The extension already uses Node.js v16
* The `getChainId` constructor parameter now expects a `Hex` return
type rather than a decimal string
* The extension was already passing in a `getChainId` parameter that
returned `Hex`
* The gas fee controller messenger now requires the
`NetworkController:stateChange` event instead of the
`NetworkController:providerConfigChange` event
* This does not apply if `onNetworkStateChange` and `getChainId` are
provided to the constructor, which is the case here.
* Update `@metamask/network-controller` dependency and peer dependency
* This dependency is only used for types, and none of the type
changes affect how the extension interacts with this controller.
The one change that did have an impact is that the constructor
parameter `onNetworkStateChange` now expects event handlers to be
passed the full network state.
Relates to #19271
* Ensure chainid always matches mainnet in test builds
This is a bit strange, but this is how the tests were setup previously.
* Fix accidental state mutation
* Remove hardcoded mainnet chain ID from test builds
The core version of NetworkControler features a controller action,
`NetworkController:getEthQuery`, which, as its name implies, can be used
to get the EthQuery instance that has been created specially to talk to
the currently selected network. As a result there is a corresponding
unit test for this action.
To make the test suites between this version of NetworkController and
core easier to compare, this commit adds the action along with its test.
* Make eth_accounts return all permitted accounts rather than just the most recently selected one
* fixup! Make eth_accounts return all permitted accounts rather than just the most recently selected one
* Trigger
---------
Co-authored-by: legobeat <109787230+legobeat@users.noreply.github.com>
Co-authored-by: Jiexi Luan <jiexiluan@gmail.com>
In the core version of NetworkController, when the `setActiveNetwork`
method updates the provider configuration object, it will capture the ID
of the network configuration used to do so within the provider config
itself. In the same way, `setProviderType` clears any ID that was
previously set from the provider config.
This commit updates this version of NetworkController to be consistent
and updates tests to match.
* snaps@0.34.0-flask.1
* Update LavaMoat policies
* Replace instances of targetKey with targetName
* Replace use of PermissionKeys with PermissionNames
* Use Flask packages in tests for now
* Bump execution env
* Add another mock
* Fix lint
In the core version of NetworkController, the `networkDetails` property
is initialized to `{ EIPS: {} }`. It is also reset to this
representation when `refreshNetwork` is called.
In this version of NetworkController, however, the default
representation of `networkDetails` is `{ EIPS: { 1559: undefined } }`.
From a consumer's perspective this doesn't make a difference — it's
practically the same. It does make a slight difference in tests,
however.
With that in mind, this commit changes the default representation to `{
EIPS: {} }`. This makes it easier to visually compare differences in the
NetworkController unit tests between core and this repo.
Update NetworkController so that when it is creating the network client
based on configuration for a custom RPC endpoint, it verifies that the
configuration object contains both a chain ID and RPC URL. This check is
already present on the core side; bringing it over makes the tests more
consistent so we can compare them more easily.
This line was accidentally left in a previous PR that swapped Nock in
the NetworkController tests for a fake provider. It does not show up in
the core version of these tests.
This test for the `destroy` method in NetworkController uses `toBe` on
the core side because the use of `toBeTruthy` produces a lint warning
there. It doesn't here, but it's good to be consistent anyway so that
comparing the differences in NetworkController tests between this
extension and core is easier.
This controller action exists within the core version of
NetworkController. Although there are no plans to make use of this
action within the extension, it has accompanying tests. So ultimately,
the goal of this commit (like others) is to make it easier to compare
differences in the NetworkController tests between this repo and core
by adding a test for the `getProviderConfig` action.
* Add Snaps privacy warning on snap install
Add snap install warning status to storage
Add storybook
Add test for snap-privacy-warning
Resolve button type issue
Fix popup display logic
Update fixture
Update popup information and read more handling
Replace deprecated button
Update unit test
* Update buttons and add cancel flow
* Refactoring (review 1)
* Add more unit tests
In the `core` version of this controller, event types are not held in an
enum but are specified directly as strings instead.
Simplifying the event types will make it easier to compare the
NetworkController unit tests between extension and core.
This makes it possible to test that mock functions are called the
correct amount of times (otherwise Jest will think that a mock function
has been called for as many tests as exist in the NetworkController unit
test suite).
On the `core` side, the tests for `NetworkController.initializeProvider`
use the `lookupNetworkTests` to automatically test the `lookupNetwork`
behavior that `initializeProvider` initiates. This commit makes use of
the helper to bring the tests closer to the `core` version.
The NetworkController tests in the `core` repo use a `refreshNetwork`
test helper to exercise the behavior performed by various methods
when switching the network. This commit brings over this test helper and
refactors tests for those methods to use it.
* Added code fences to the following controllers: app-state, metametrics, preferences
* Fixed prettier
* Updated code to be align with new changes in MMI
* Changing code fences
* Remove uneeded files
* Fixed tests
* Fixed code fence
* Changing logic to use async/await
* Removed accountAddress
* Reverted code from develop
Hex and number responses from the `net_version` request are now
accepted. While most chains return decimal strings for this request,
some chains were returning hex responses instead and failing our
validation for this request (which was added in v10.30.0). This
resolves that problem.
Support for number responses was added because it likely worked in
older versions as well, so support is maintained to avoid similar
problems.
Fixes#19151
The `lookupNetwork` unit tests have been updated to expand test
coverage and match the unit tests for the core network controller. A
helper function `lookupNetworkTests` has been copied from core. It
covers most of the behavior of the function. Vidation tests and
functional tests not covered in core have been retained, but any tests
that are now redundant have been deleted.
Relates to #1197
The detection of the Infura "blocked" status has been updated to apply
only to built-in networks. The message we show to users in this state
is meant only for Infura; we don't want to show it for third-party RPC
APIs that happen to use the same error response.
This brings the network controller further in alignment with the core
network controller.
This isn't tested, but it was found in the course of porting unit tests
from core to extension. It will be covered by these tests, which will
be added in the next PR.
NetworkController doesn't handle `eth_subscribe` or `eth_unsubscribe`
specially, but as it's supported by Infura, we want to make sure we
exercise these RPC methods in the network client tests, even if it is
just to ensure that they get passed through to the network.
We had tests for these RPC methods, but they were commented out in
c095b1accd when the network client code
was extracted to a separate file. At the time we were considering adding
subscription- and filter-based middleware to NetworkController, and so
we commented out the tests for `eth_subscribe` and `eth_unsubscribe`
temporarily until we could rewrite them in a way that would exercise the
new middleware. We reverted that change in
bd23a49013, which meant that we could
restore the existing tests, but it appears that this task was not caught
during review. This commit takes care of restoring them.
Co-authored-by: legobeat <109787230+legobeat@users.noreply.github.com>
We now set the network status to "unknown" rather than "unavailable"
when the network ID is invalid. This better reflects what we know when
this happens, and it makes the network controller better aligned with
the core network controller.
This was accomplished by using a regular error for the network ID
assertion rather than using `assert` directly. `assert` would throw an
error with a `code` property, which resutled in us treating it like an
RPC error.
This isn't tested, but it was found in the course of porting unit tests
from core to extension. It will be covered by these tests, which will
be added in the next PR.
This change should have no functional impact because we treat these two
network statuses as equivalent. The distinction between unknown and
unavailable is useful only for debugging.
