The Sentry DSN is now expected to be provided via environment variable
for production builds. The build script will fail if it is missing, and
an error will be thrown at runtime if it is missing.
The `SENTRY_DSN` environment variable has been set in CI to the old
value for `SENTRY_PROD_DSN`. We can migrate to a new DSN at some point
in the future.
In a non-production environment, Sentry was configured to send error
reports to a "test" MetaMask project. It will still do this during e2e
tests, but in development Sentry is now disabled completely.
In practice this was never useful in development.
* Fix popup/notification when browser is in fullscreen, primarily on OSX.
The issue was reported internally via Slack. User was running Mac OSX Chrome in fullscreen mode where Chrome is created in a new Desktop workspace.
The issue reproduced on OSX Chrome in fullscreen/maximized view overrides the explicitly set width and height for `windows.create()`. Possibly not overrides, but creates a window based off of the window that it was created from. Found a related [Chromium bug](https://bugs.chromium.org/p/chromium/issues/detail?id=263092&q=window%20create%20width%20os%3DMac&can=2).
The fullscreen `popup.left` pixel will calculate the window position incorrectly since we set and assume the width of the created window. The incorrect `left` position the window and transition the focus Desktop/Workspace incorrectly and make is seem to lose focus of the new window/workspace. Incidentally this will make the popup full width/height, and create a new workspace for the view, which we have no control over until Chrome
fixes it.
This will check if the popup is 'fullscreen', which it gets passed from the origin window, if so then don't reposition the window. If Chrome fixes the issue we can revert this change.
* Feedback commit
Co-authored-by: Mark Stacey <markjstacey@gmail.com>
Co-authored-by: Mark Stacey <markjstacey@gmail.com>
The `extra` property of errors sent to Sentry is sometimes not
initialized when we add the application state. A check has been added
to initialize it if it's missing.
I suspect that this changed with v5 of `@sentry/browser`, though I
can't find any explicit confirmation of this in their changelog.
The state snapshot that was attached to Sentry errors was removed
recently in #8794 because it had become too large. The snapshot has
now been restored and reduced in size.
A utility function has been written to reduce the state object to just
the requested properties. This seemed safer than filtering out state
that is known to be large or to contain identifiable information.
This is not a great solution, as now knowledge about the state shape
resides in this large constant, but it will suffice for now. I am
hopeful that we can decorate our controllers with this metadata in the
future instead, as part of the upcoming background controller refactor.
A separate `getSentryState` global function has been added to get the
reduced state, so that the old `getCleanAppState` function that we used
to use could remain unchanged. It's still useful to get that full state
copy while debugging, and in e2e tests.
This migration had referred to the non-existent
`TransactionsController` instead of `TransactionController`, so it
effectively did nothing. Now it should work.
This migration hasn't been included in any release yet, so we can fix
it in-place instead of adding an additional corrected migration.
The migration comment has also been updated, as it was inaccurate.
This method was accidentally broken with the introduction of the
permissions controller, as this was missing from the list of safe
methods.
It is now included in the list of safe methods.
Fixes#8993
The currency rate controller is updated upon each network change, as
the "native currency" is network-dependent and might have changed.
However, any thrown errors were being caught and passed to an empty
callback.
The errors are now re-thrown in the callback. As a result, the errors
will now be printed to the console and sent to Sentry.
It seems that this blocklist checker never worked correctly. Ever since
the initial commit, it was comparing the Number `1` to the `networkId`,
which is a string. Additionally, even if it did throw, the transaction
continued unhindered. The user could still approve it, and there was no
indication shown to the user that anything went wrong. Also some of the
blocklist entries were incorrectly mixed-case, and were never hit.
We can remove this for now, and re-add it later on after we rewrite the
transaction controller.
The `metamaskNetworkId` property in the `txMeta` for incoming
transactions was incorrectly set as a Number instead of a String. This
change was made accidentally as part of #8627.
As a result incoming transactions were being excluded from the
transaction list, as they didn't have a matching network ID.
`metamaskNetworkId` is now set to a string, and a migration has been
added to ensure `metamaskNetworkId` is converted to a string for any
incoming transactions in state.
An optimization in `account-tracker.js` was being skipped consistently
due to a type error (a number was being compared to a string).
The optimization in this case was to update the balances for all
accounts with a single request, rather than one request per account.
The `activeTab.id` property is relied upon in the connected sites modal
to prevent the user from manually connecting to the MetaMask extension
itself. Unfortunately the `id` property was never set.
`id` is now set on the `activeTab` state, so manually connecting to the
extension UI is now impossible.
The `activeTab` state is now set to an empty object if the `origin` of
the active tab is missing or invalid. It can be invalid if the URL
passed to the `URL` constructor is missing a scheme (e.g.
`about: blank`).
There are currently no cases where the rest of the data in `activeTab`
is useful in the absence of an `origin`. This will make upcoming UI
logic changes a bit simpler than they would be otherwise. Now we can
assume that if any property is set on `activeTab`, it must have a valid
`origin`.
There were three cases where execution unintentionally continued after
an error was encountered. These cases likely are impossible to
encounter in practice due to recent validation improvements in the
`eth-json-rpc-middleware/wallet` module, but they were broken
nonetheless.
Execution inside the Promise constructor now halts immediately after
`reject` is called.
* Use over the whole stringified error object which doesn't show the actual error message that is set as the
Co-authored-by: Mark Stacey <markjstacey@gmail.com>
* Feedback commit
The code for checking whether a transaction was dropped or not was
refactored in #8398, but in the process an off-by-one error was
introduced.
The old version of `_checkIfTxWasDropped` would query for an updated
transaction count from the network, and would consider the pending
transaction to be dropped if the count was above the nonce. However,
the version introduced in #8398 considers the transaction to be dropped
if the count is above *or equal to* the nonce.
The pending transaction nonce is expected to be equal to the
transaction count, because the nonce starts at zero. The transaction
count is equal to the expected next nonce.
The variable name has been updated to make this more clear
(`networkNextNonce` is how the `nonce-tracker` refers to this value).
`parseInt` is now called with an explicit radix of `16` as well, to
ensure both nonce strings are always parsed as hex. In all cases I am
aware of, these nonce strings were prefixed by `0x`, meaning that
`parseInt` would default to a radix of `16`, so this likely doesn't
constitute a functional change.
Fixes#8688
Brad Decker
Mark Stacey
Thomas Huang
ryanml
Whymarrh Whitby
MetaMask Bot
Erik Marks
matteopey
Esteban Miño
