* feat(878): implement new incoming transaction toggle networks for setting and onboarding
* Update state snapshots
* feat(878): change gaps, migration types based on comment
---------
Co-authored-by: Mark Stacey <markjstacey@gmail.com>
Removes the `Website Accessed window.web3 Shim` event from the `metamask_logWeb3ShimUsage` RPC method implementation. The method itself displays an alert to the user if a website attempts to access the `window.web3` shim, which we replaced the original, functional `window.web3` object with after said object was removed. This seems potentially useful, because we still get 5-star reviews on [the legacy web3 extension](https://addons.mozilla.org/en-US/firefox/addon/metamask-legacy-web3/).
The associated metrics event, on the other hand, is useless. It is rife with false positives, and doesn't tell us anything that we can't learn from download data for the legacy web3 extension. It's time to get rid of it.
* fix(settings): fixed two IPFS gateway issues
- adds back in two bugfixes that were originally in #19283
- fixes#16871
- fixes#18140
- achieves 100% code coverage for /ui/pages/settings/security-tab
- removes the npm package `valid-url`, which has not been updated in 10 years
* changes after #20172 was merged
* improved URL validation (specifically spaces)
* better Jest coverage
* response to legobeat review
* fixing lint and Jest
Remove the IncomingTransactionController and replace it with an internal helper class.
Move incoming transactions into the central transactions object.
Create a new RemoteTransactionSource interface to decouple incoming transaction support from Etherscan.
Split the incoming transaction logic into multiple files for easier maintenance.
Sentry breadcrumb collection during initialization was broken in #20529
because we failed to consider that the `getSentryState` check was also
used for an opt-in check in the `beforeBreadcrumb` hook.
I had assumed that `getSentryState` was only used to get state to add
additional context to an error report. But the function has a second
purpose: to get state for the purposes of checking whether the user has
opted into MetaMetrics. In this second case, `mostRecentRetrievedState`
is sometimes unset (which violates an assumption made in #20529)
The `getMostRecentPersistedState` hook removed in #20529 has been
restored, ensuring that the `getSentryState` function returns Sentry
state after loading state for the first time, but before the first
error has occurred.
This mistake didn't cause e2e tests to fail because multiple errors are
currently thrown in the background upon initialization on `develop`
(relating to Snow scuttling). These errors were early enough that they
happened before the console logs that our breadcrumb test was testing
for. When #20529 was ported onto the v10.34.5 RC, these errors were not
present so the test failed correctly.
In the case where an error is thrown in the UI before initialization
has finished, we aren't capturing the application state correctly for
Sentry errors. We had a test case for this, but the test case was
broken due to a mistake in how the `network-store` was setup (it was
not matching the behavior of the real `local-tstore` module).
The pre-initialization state capture logic was updated to rely solely
upon the `localStore` instance used by Sentry to determine whether the
user had opted-in to metrics or not. This simplifies the logic a great
deal, removing the need for the `getMostRecentPersistedState` state
hook. It also ensures that state is captured corretly pre-
initialization in both the background and UI.
* Fix Sentry MetaMetrics detection
The refactor of the Sentry state in #20491 accidentally broke our opt-
in detection. The opt-in detection has been updated to look for both
types of application state (during and after initialization).
* Continue suppressing breadcrumbs during onboarding
* Fix how onboarding status is retrieved
The check for whether the user had completed onboarding assumed that
the application state was post-initialization UI state. It has been
updated to handle background state and pre-initialization state as
well.
* Remove unnecessary optional chain operators
* Add missing optional chain operator
* Fix JSDoc description parameter type
* Initialize composable observable store after update
The composable observable store now updates state immediately when the
structure is updated. Previously each store would only be updated after
the first state change. This ensures that the composable observable
store state is always complete.
* SUpport falsy controller state
We now use the nullish coalescing operator when checkint store.state, so that we don't accidentally ignore falsy state.
Co-authored-by: Frederik Bolding <frederik.bolding@gmail.com>
* Add test for falsy controller state
* Update state snapshots
A change on `develop` required another state update.
---------
Co-authored-by: Frederik Bolding <frederik.bolding@gmail.com>
* Improve Sentry state pre-initialization
Previously the masked state snapshot sent to Sentry would be blank for
errors that occured during initialization. Instead we'll now include
some basic information in all cases, and a masked copy of the persisted
state if it happens after the first time the persisted state is read.
* Add test
* Fix crash when persisted state not yet fetched
* Add descriptions for initial state hooks
* Update comments to reflect recent changes
* Re-order imports to follow conventions
* Move initial state hooks back to module-level
The initial state hooks are now setup at the top-level of their module.
This ensures that they're setup prior to later imports. Calling a
function to setup these hooks in the entrypoint module wouldn't
accomplish this even if it was run "before" the imports because ES6
imports always get hoisted to the top of the file.
The `localStore` instance wasn't available statically, so a new state
hook was introduced for retrieving the most recent retrieved persisted
state.
* Fix error e2e tests
The backup module has been renamed so that it isn't confused with a
controller. The "backup controller" has never managed any state or
extended the controller base class. It is a module for backing up data,
but it's not a controller.
The backup controller's current inclusion in the `store` and `memstore`
`ComposableObservableStore`s was getting in the way of some other
enhancements to that class (which will come in a later PR).
The unflattened background state is now attached to any Sentry errors
from the background process. This provides a clearer picture of the
state of the wallet, and unblocks further improvements to Sentry state
which will come in later PRs.
The state mask used to anonymize the Sentry state snapshots has been
split into UI and background masks. This was done to simplify later
refactors. There should be no functional changes.
* Add AppMetadataController so current and previous application and migration version can be captured in sentry
* Add currentAppVersion, previousAppVersion, previousMigrationVersion, currentMigrationVersion to SENTRY_OBJECT
* Update app/scripts/controllers/app-metadata.ts
Co-authored-by: Mark Stacey <markjstacey@gmail.com>
* Update app/scripts/controllers/app-metadata.ts
Co-authored-by: Mark Stacey <markjstacey@gmail.com>
* Update app/scripts/controllers/app-metadata.ts
Co-authored-by: Mark Stacey <markjstacey@gmail.com>
* Fix types
* Add tests for app-metadata.test.ts
* Lint fixes
* Modify loadStateFromPersistence to return the whole versionData object, so that the migration version can be passed to the metamask-controller on instantiation
* Remove reference to implementation details in test descriptions in app/scripts/controllers/app-metadata.test.ts
* Reset all mocks afterEach in AppMetadataController
* Refactor AppMetadataController to be passed version instead of calling platform.version directly (for ease of unit testing the MetaMask Controller)
* Make maybeUpdateAppVersion and maybeUpdateMigrationVersion private, and remove unit tests of those specific functions
---------
Co-authored-by: Mark Stacey <markjstacey@gmail.com>
An import was introduced in #20125 that was broken. It was importing
from `app/` instead of using a relative import. This was causing the
CI "depcheck" job to fail. The import has been updated to use a
relative path.
* Capture Sentry errors prior to initialization
Sentry errors captured before/during the wallet initialization are
currently not captured because we don't have the controller state yet
to determine whether the user has consented.
The Sentry setup has been updated to check the persisted state for
whether the user has consented, as a fallback in case the controller
state hasn't been initialized yet. This ensures that we capture errors
during initialization if the user has opted in.
* Always await async check for whether the user has opted in
* Remove unused import
* Update JSDoc return type
* Remove unused driver method
* Fix metametrics controller unit tests
* Fix e2e tests
* Fix e2e test on Firefox
* Start session upon install rather than toggle
* Allow user to turn off IPFS gateway resolution
* Add end to end test for toggle on and off
* Fix jest tests and snapshots
* Change variable name
* Implement provided content
* Use MetaMask eth instead
* Allow searching for ENS setting
* Fix jest
---------
Co-authored-by: Brad Decker <bhdecker84@gmail.com>
* Update sentry/cli to 2.19.4
* Ensure sentry files are loaded and referenced with a valid url
* Temp to eliminate errors in sentry (should be split into other PRs)
* Rename `provider` to `providerConfig`
The network controller `provider` state has been renamed to
`providerConfig`. This better reflects what this state is, and makes
this controller more closely aligned with the core network controller.
All references to the provider configuration have been updated to
prefer `providerConfig` over `provider`, to make the distinction clear
between a provider and provider config.
Closes#18902
* Add migration
* feat: add yaml feature management
Add yaml feature file per build type.
Also add method to parse yaml and set
enabled features env to true. The build
process will then replace any process.env[feature]
that exists on the config by its value
* chore: add example for desktop
* Added initial draft of build features
* [TMP] Sync between computers
* Is able to succesfully build stable extension with snaps feature
* Removing var context from builds.yml
* Add asssets to builds.yml
* Minor bug fixes and removing debug logs
* [WIP] Test changes
* Removed TODOs
* Fix regession bug
Also
* remove debug logs
* merge Variables.set and Variables.setMany with an overload
* Fix build, lint and a bunch of issues
* Update LavaMoat policies
* Re-add desktop build type
* Fix some tests
* Fix desktop build
* Define some env variables used by MV3
* Fix lint
* Fix remove-fenced-code tests
* Fix README typo
* Move new code
* Fix missing asset copy
* Move Jest env setup
* Fix path for test after rebase
* Fix code fences
* Fix fencing and LavaMoat policies
* Fix MMI code-fencing after rebase
* Fix MMI code fencing after merge
* Fix more MMI code fencing
---------
Co-authored-by: cryptotavares <joao.tavares@consensys.net>
Co-authored-by: Frederik Bolding <frederik.bolding@gmail.com>
Co-authored-by: Brad Decker <bhdecker84@gmail.com>
The network controller method `setProviderType` is now async, and the
async operation `_setProviderConfig` called at the end of the method is
now awaited.
Because the only async operation was the last step, this should have no
impact upon the flow of execution. The only functional change is that
now any callers have the option of waiting until the network switch
operation has completed.
One such change was made, in the `switch-ethereum-chain` middleware. As
a result, an error thrown while the network is switching will now
be thrown in this middleware and returned to the dapp as an internal
error.
Relates to https://github.com/MetaMask/metamask-extension/issues/18587
* use session storage, instead of chrome.runtime.onStartup and globalThis, for firstTimeLoaded architecture
* Ensure account tracker accounts remain defined upon service worker restart
* lint fix
* Simplify code
* Only call browser.storage.session in mv3
* Only call browser.storage.session.set after resetStates in mv3
* fix metamask controller reset states unit tests
* fix test
* fix test
* Actually fix tests
* lint fix
The package `safe-event-emitter` has been updated to v2. This update
includes renaming the package to be scoped under `@metamask`, and it
includes a TypeScript migration.
We want to convert NetworkController to TypeScript in order to be able
to compare differences in the controller between in this repo and the
core repo. To do this, however, we need to convert the dependencies of
the controller to TypeScript.
As a part of this effort, this commit converts
`shared/constants/metametrics` to TypeScript. Note that simple objects
have been largely replaced with enums. There are some cases where I even
split up some of these objects into multiple enums.
Co-authored-by: Mark Stacey <markjstacey@gmail.com>
The `network` store of the network controller crams two types of data
into one place. It roughly tracks whether we have enough information to
make requests to the network and whether the network is capable of
receiving requests, but it also stores the ID of the network (as
obtained via `net_version`).
Generally we shouldn't be using the network ID for anything, as it has
been completely replaced by chain ID, which all custom RPC endpoints
have been required to support for over a year now. However, as the
network ID is used in various places within the extension codebase,
removing it entirely would be a non-trivial effort. So, minimally, this
commit splits `network` into two stores: `networkId` and
`networkStatus`. But it also expands the concept of network status.
Previously, the network was in one of two states: "loading" and
"not-loading". But now it can be in one of four states:
- `available`: The network is able to receive and respond to requests.
- `unavailable`: The network is not able to receive and respond to
requests for unknown reasons.
- `blocked`: The network is actively blocking requests based on the
user's geolocation. (This is specific to Infura.)
- `unknown`: We don't know whether the network can receive and respond
to requests, either because we haven't checked or we tried to check
and were unsuccessful.
This commit also changes how the network status is determined —
specifically, how many requests are used to determine that status, when
they occur, and whether they are awaited. Previously, the network
controller would make 2 to 3 requests during the course of running
`lookupNetwork`.
* First, if it was an Infura network, it would make a request for
`eth_blockNumber` to determine whether Infura was blocking requests or
not, then emit an appropriate event. This operation was not awaited.
* Then, regardless of the network, it would fetch the network ID via
`net_version`. This operation was awaited.
* Finally, regardless of the network, it would fetch the latest block
via `eth_getBlockByNumber`, then use the result to determine whether
the network supported EIP-1559. This operation was awaited.
Now:
* One fewer request is made, specifically `eth_blockNumber`, as we don't
need to make an extra request to determine whether Infura is blocking
requests; we can reuse `eth_getBlockByNumber`;
* All requests are awaited, which makes `lookupNetwork` run fully
in-band instead of partially out-of-band; and
* Both requests for `net_version` and `eth_getBlockByNumber` are
performed in parallel to make `lookupNetwork` run slightly faster.
