* 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 and test log.info calls run for each migration
In migrator/index.js, log.info is called before an after each migration.
These calls are intended to produce breadcrumbs to be captured by sentry
in cases where errors happen during or shortly after migrations are run.
These calls were not causing any output to the console because the log.setLevel
calls in ui/index.js were setting a 'warn value in local storage that was being
used by logLevel in the background.
This commit fixes the problem by setting the `persist` param of setLevel to
false, so that the background no longer reads the ui's log level.
Tests are added to verify that these logs are captured in sentry breadcrumbs
when there is a migration error due to an invariant state.
* Improve breadcrumb message matching
The test modified in this commit asserts eqaulity of messages from breadcrumbs
and hard coded expected results. This could cause failures, as sometimes the
messages contain whitespace characters. This commit ensures the assertions only
check that the expected string is within the message string, ignoring extra
characters.
* fix(custodial-signing): set approved status in tx controller in MMI logic
* Fixed the issue that was not showing custody-confirm-link
---------
Co-authored-by: Shane Terence Odlum <shane.odlum@consensys.net>
* 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>
* Alter behaviour in MMI controller to use the original code path for signed messages that are from non custodial accounts
* Improved readability
* Removed unused import
---------
Co-authored-by: Shane Terence Odlum <shane.odlum@consensys.net>
* fixed connect mmi button several issues
* Fixed snapshot
* Improved multiple things
* running yarn dedupe
* Update LavaMoat policies
* For some reason, this.mmiConfigurationController.store.mmiConfiguration?.portfolio sometimes is undefined, added [] if null.
Moved the || {} outside the find method
* minor improvements
---------
Co-authored-by: MetaMask Bot <metamaskbot@users.noreply.github.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
Migration #77 would set the `TokenListController.tokensChainsCache`
state to `undefined` if it wasn't already set to anything when that
migration was run. This is probably harmless except that it results
in Sentry errors during migrations, and it results in that property
having a value (at least temporarily) that doesn't match its type.
Migration #77 has been updated to prevent this property from being
set to `undefined` going forward. A new migration has been added to
delete this value for any users already affected by this problem. The
new migration was named "92.1" so that it could run after 92 but before
93, to make backporting this to v10.34.x easier (v10.34.x is currently
on migration 92). "92.1" is still a valid number so this should work
just as well as a whole number.
Additional validation has been added for persisted state metadata.
Beforehand we just checked that the state itself wasn't falsy. Now we
ensure that the metadata is an object with a valid version as well.
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).
* capture exception for sentry when invariant conditions are met in migration 82
* Code cleanup
* Capture exceptions in invariant conditions for migrations 83,84,85,86,89,91,93,94
* Update app/scripts/migrations/082.test.js
Co-authored-by: Mark Stacey <markjstacey@gmail.com>
* Code cleanup
* Fix SentryObject type declaration
* Stop throwing error if preferences controller is undefined
* Refactor 084 and 086 to remove double negative
* Capture exceptions for invariant states in in migrations 87,88,90 and 92
* lint fix
* log warning in migration 82 when preferences controller is undefined
---------
Co-authored-by: Mark Stacey <markjstacey@gmail.com>
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>
* Reorganize Sentry error e2e tests
The tests have been reorganized into different describe blocks. Each
describe block is for either before or after initialization, and either
with or without opting into metrics.
This was done to simplify later test additions. The conditions for each
test are now in the describe block, letting us test additional things
in each of these conditions. The conditions were flattened to a single
level to avoid excessive indentation.
* Add error e2e test for background and UI errors
The Sentry e2e tests before initialization only tested background
errors, and the after initialization tests only tested UI errors. Now
both types of errors are tested in both scenarios.
* Add error e2e tests for Sentry error state
E2E tests have been added to test the state object sent along with each
Sentry error.
At the moment this object is empty in some circumstances, but this will
change in later PRs.
* Rename throw test error function
* Only setup debug/test state hooks in dev/test builds
The state hooks used for debugging and testing are now only included in
dev or test builds. The function name was updated and given a JSDoc
description to explain this more clearly as well.
* Add state snapshot assertions
State snapshot assertions have been added to the e2e error tests. These
snapshots will be very useful in reviewing a few PRs that will follow
this one.
We might decide to remove these snapshots after this set of Sentry
refactors, as they might be more work to maintain than they're worth.
But they will be useful at least in the short-term.
The login step has been removed from a few tests because it introduced
indeterminacy (the login process continued asynchronously after the
login, and sometimes was not finished when the error was triggered).
* Ensure login page has rendered during setup
This fixes an intermittent failure on Firefox
* Format snapshots with prettier before writing them
* Use defined set of date fields rather than infering from name
* Remove waits for error screen
The error screen only appears after a long timeout, and it doesn't
affect the next test steps at all.
* refactor: use addNewAccount from core KeyringController
* refactor: replace missed interaction
* refactor: select account only when is new
* refactor: use getAccounts to check if account is new
The "last fetched" state for the `PhishingController` has been deleted
to force an immediate full update of the phishing configuration state.
We're doing this because the state was cleared in v10.34.2 because the
format of that state had changed.
This has been implemented in migration 92. The previous migration 92
has been renamed to 93 because it won't be included until a future
release. We need the migrations to remain sequential, and this will
save us from having to resolve a complex conflict when releasing this.
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.
* allow `SnapController` to call `SnapsRegistry:update`
* call `SnapController:updateBlockedSnaps` on extension startup
* only check if at least one snap is installed
* Fix migration 88 to handle the case where chainId keys can be undefined
* Add migration 91 to delete network configurations that have no chainId
* Lint fix
* Update migration number
* Update migration 91 description
* Update version numbers in 091.test.js
* Fix 088.test.ts typescript problem
* Fix 088.test.ts typescript problem
* Update app/scripts/migrations/091.ts
Co-authored-by: Mark Stacey <markjstacey@gmail.com>
* Change app/scripts/migrations/091.test.js to typescript
* clone oldstorage for test result comparisons in 091.test.js
* Lint fix
* Add missing test case
---------
Co-authored-by: Mark Stacey <markjstacey@gmail.com>
* Remove fallback phishing warning configuration
The package `@metamask/phishing-controller` has been updated from v4
v6. The only breaking changes are a minimum Node.js version bump, and
the removal of the fallback phishing configuration.
The fallback phishing configuration was resulting in MetaMask being
incorrectly flagged as malware, and the stale config was causing
problems for sites that had been blocked in the past but have since
been unblocked. This should substantially reduce the bundle size as
well.
* Update LavaMoat policies
* Update test state to include example blocked site
---------
Co-authored-by: MetaMask Bot <metamaskbot@users.noreply.github.com>
* Handle the case where tokensChainsCache data is undefined in migration 77
* Delete parts of state that should have been removed in migrations 82,84,86 and 88
* Create 077-supplements.md
* Update 077-supplements.md
* Update 077-supplements/*.js code comments
* Fix types and jsdoc
* Type/lint fix
* Cleanup
* Add 'should set data to an empty object if it is null' test case to 077.test.js
* Update app/scripts/migrations/077.test.js
Co-authored-by: Mark Stacey <markjstacey@gmail.com>
* Modify deletion criteria so that all decimal chain id proprties are deleted in migration 88 supplement
* Readme.md
* Update app/scripts/migrations/077.test.js
Co-authored-by: Mark Stacey <markjstacey@gmail.com>
* Update app/scripts/migrations/077.test.js
Co-authored-by: Mark Stacey <markjstacey@gmail.com>
* Update app/scripts/migrations/077.test.js
Co-authored-by: Mark Stacey <markjstacey@gmail.com>
* Lint fix
* Only delete decimal chain id keyed-entries in migration 88 supplement if there are hexadecimal keyed entries as well
* Remove redundant test
* Add 'does not delete' cases for nftcontroller related tests in 077.test.js
---------
Co-authored-by: Mark Stacey <markjstacey@gmail.com>
* 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
