This commit fulfills a long-standing desire to get the extension using
the same network controller as mobile by removing NetworkController from
this repo and replacing it with NetworkController from the
`@metamask/network-controller` package.
The new version of NetworkController is different the old one in a few
ways:
- The new controller inherits from BaseControllerV2, so the `state`
property is used to access the state instead of `store.getState()`.
All references of the latter have been replaced with the former.
- As the new controller no longer has a `store` property, it cannot be
subscribed to; the controller takes a messenger which can be
subscribed to instead. There were various places within
MetamaskController where the old way of subscribing has been replaced
with the new way. In addition, DetectTokensController has been updated
to take a messenger object so that it can listen for NetworkController
state changes.
- The state of the new controller is not updatable from the outside.
This affected BackupController, which dumps state from
NetworkController (among other controllers), but also loads the same
state into NetworkController on import. A method `loadBackup` has been
added to NetworkController to facilitate this use case, and
BackupController is now using this method instead of attempting to
call `update` on NetworkController.
- The new controller does not have a `getCurrentChainId` method;
instead, the chain ID can be read from the provider config in state.
This affected MmiController. (MmiController was also updated to read
custom networks from the new network controller instead of the
preferences controller).
- The default network that the new controller is set to is always
Mainnet (previously it could be either localhost or Goerli in test
mode, depending on environment variables). This has been addressed
by feeding the NetworkController initial state using the old logic, so
this should not apply.
The autolock field on the Settings screen — the field that allows users
to set the duration that MetaMask will wait for until automatically
locking — does not always accept decimal numbers. This breaks the e2e
test for this feature as it attempts to set this field to "0.1".
More specifically, the React component responsible for this field passes
whatever the user inputs through the `Number` function immediately and
then uses this to repopulate the input. Therefore, if the user enters
"3" followed by a ".", `Number("3.")` will be called. This evaluates to
the number 3, and "3" becomes the new value of the field. As a result,
the "." can never be typed.
Curiously, this behavior only happens in Firefox; Chrome seems to
keep the "." in the input field when it's typed. This happens because
`onChange` event doesn't seem to get fired until a number is typed
*after* the ".". This may be due to underlying differences in the DOM
between Chrome and Firefox.
Regardless, always passing the input through `Number` creates other odd
behavior, such as the fact that the input can never be cleared (because
`Number("")` evaluates to 0).
This commit solves these problems by saving the "raw" version of the
user's input as well as the normalized version. The raw version is
always used to populate the input, whereas the normalized version is
saved in state.
These tests were present in the core version of the NetworkController
tests, but not here. Add them makes it easier to visually compare
differences in the tests between core and this repo.
Update NetworkController tests to replace `NETWORK_TYPES.<NETWORK NAME>`
with `NetworkType.<network name>`. This makes it easier to visually
compare differences in the tests between core and this repo.
* feat: add new linea mainnet network
* fix: removed unused condition + lint code
* fix: update tests + fix network tab issue
* feat: add feature toggle for linea mainnet
* fix: add feature toggle for linea mainnet
* feat: add linea mainnet logo
* update @metamask/eth-json-rpc-infura package to support linea networks
* update linea mainnet block explorer url
* fix: refactor linea mainnet feature toggle
* fix: update linea mainnet chain id and rpc url
* fix: update settings-search unit test
* fix: update linea mainnet feature flag
* fix: remove useless async function keyword for linea mainnet feature flag
* Sync NC lookupNetwork tests with core
This makes it easier to visually compare differences in the
NetworkController unit tests between core and this repo.
* Add types for toBeFulfilled matcher
* Fix lint again
* 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
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.
