* allow `SnapController` to call `SnapsRegistry:update`
* call `SnapController:updateBlockedSnaps` on extension startup
* only check if at least one snap is installed
* initial fixes to E2Es
* changed test website
* final E2E fixes
* fixed getentropy test
* missing scroll fix
* scrollfix for bip44 firefox
* added new function and edited tests
* BannerBase to TS
* snapshot updates
* more snapshot updates
* addressing type definition error
* updating eth-sign-modal snapshot
* Updates to stories, types and adding data-testid
* Updating snapshots
* updating snapshot of blockaid-banner-alert and adding unit test for childrenWrapperProps
* BannerBase updates to stories, adding locale for close button, removing static data-testid in favor of using it at the instance, updating snapshots associated with those changes
* Removing incorrect arg from storybook file
* Updating html element in security provider e2e test to match BannerBase. Also updating snapshot of ConfirmTransaction page
* Fixing e2e tests
---------
Co-authored-by: georgewrmarshall <george.marshall@consensys.net>
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.
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.
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.
* feat(action): github action to create bug report issue at RC cut
* feat(action): github action to close bug report issue once release is ready
* fix(action): replace main by master
* fix(action): create event does not support branch filter
* fix(action): indentation
* fix(action): actionlint erors
* fix(action): actionlint erors 2
* fix(action): actionlint erors 3
* fix(action): replace npm by yarn for consistency
* 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.
* 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>
* 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
* 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
The CI job `test-deps-depcheck` was optional, allowing PRs to be merged
that included dependency errors. It is now a required job, ensuring
that no such errors are introduced in the future.
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.
* 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 E2E test scripts now have a flag for updating E2E test snapshots.
The flag has been documented as well. This makes it easier to update
snapshots and raises visbility of this feature.
* 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>
* Enable Snaps feature flag in stable
* Run snaps E2Es in stable
* Fix CI config indentation
* Fix CI paths
* Update LavaMoat policies
* Update iframe URL
* Exclude some tests from running in stable e2e
* Disable another test on stable
* Bump to 1.0.1
* Fix config.yml issue due to staleness
* Stop running newly added test
* Update snapshots used for E2E
* Use shallow-git-clone
* 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>
