This method adds the given account to the given origin's list of
exposed accounts. This method is not yet used, but it will be in
subsequent PRs (e.g. #8312)
This method has been added to the background API, and a wrapper action
creator has been written as well.
Now that identities are available synchronously in the permissions
controller, accounts can be validated synchronously as well. Any
account the user wants to give permissions to should already be tracked
as an identity in the preferences controller.
* Fix order of accounts in `eth_accounts` response
The accounts returned by `eth_accounts` were in a fixed order - the
order in which the keyring returned them - rather than ordered with the
selected account first. The accounts returned by the `accountsChanged`
event were ordered with the selected account first, but the same order
wasn't used for `eth_accounts`.
We needed to store additional state in order to determine the correct
account order correctly on all dapps. We had only been storing the
current selected account, but since we also need to determine the
primary account per dapp (i.e. the last "selected" account among the
accounts exposed to that dapp), that wasn't enough.
A `lastSelected` property has been added to each identity in the
preferences controller to keep track of the last selected time. This
property is set to the current time (in milliseconds) whenever a new
selection is made. The accounts returned with `accountsChanged` and by
`eth_accounts` are both ordered by this property.
The `updatePermittedAccounts` function was merged with the internal
methods for responding to account selection, to keep things simpler. It
wasn't called externally anyway, so it wasn't needed in the public API.
* Remove caveat update upon change in selected account
The order of accounts in the caveat isn't meaningful, so the caveat
doesn't need to be updated when the accounts get re-ordered.
* Emit event regardless of account order
Now that we're no longer relying upon the caveat for the account order,
we also have no way of knowing if a particular account selection
resulted in a change in order or not. The notification is now emitted
whenever an exposed account is selected - even if the order stayed the
same.
The inpage provider currently caches the account order, so it can be
relied upon to ignore these redundant events. We were already emiting
redundant `accountsChanged` events in some cases anyway.
Selecting a new account now results in all domains that can view this
change being notified. Previously only the dapp in the active tab was
being notified (though not correctly, as the `origin` was accidentally
set to the MetaMask chrome extension origin).
This handling of account selection has been moved into the background
to minimize the gap between account selection and the notification
being sent out. It's simpler for the UI to not be involved anyway.
Previously all browser globals were allowed to be used anywhere by
ESLint because we had set the `env` property to `browser` in the ESLint
config. This has made it easy to accidentally use browser globals
(e.g. #8338), so it has been removed. Instead we now have a short list
of allowed globals.
All browser globals are now accessed as properties on `window`.
Unfortunately this change resulted in a few different confusing unit
test errors, as some of our unit tests setup assumed that a particular
global would be used via `window` or `global`. In particular,
`window.fetch` didn't work correctly because it wasn't patched by the
AbortController polyfill (only `global.fetch` was being patched).
The `jsdom-global` package we were using complicated matters by setting
all of the JSDOM `window` properties directly on `global`, overwriting
the `AbortController` for example.
The `helpers.js` test setup module has been simplified somewhat by
removing `jsdom-global` and constructing the JSDOM instance manually.
The JSDOM window is set on `window`, and a few properties are set on
`global` as well as needed by various dependencies. `node-fetch` and
the AbortController polyfill/patch now work as expected as well,
though `fetch` is only available on `window` now.
The tests for the detect-tokens controller were nearly all broken. They
have been fixed, and a few improvements were made to controller itself
to help with this.
* The core `detectNewTokens` method has been updated to be async, so
that the caller can know when the operation had completed.
* The part of the function that used `Web3` to check the token balances
has been split into a separate function, so that that part could be
stubbed out in tests. Eventually we should test this using `ganache`
instead, but this was an easier first step.
* The internal `tokenAddresses` array is now initialized on
construction, rather than upon the first Preferences controller update.
The `detectNewTokens` function would have previously failed if it ran
prior to this initialization, so it was failing if called before any
preferences state changes.
Additionally, the `detectTokenBalance` function was removed, as it was
no longer used.
The tests have been updated to ensure they're actually testing the
behavior they purport to be testing. I've simulated a test failure with
each one to check that it'd fail when it should. The preferences
controller instance was updated to set addresses correctly as well.
* Connect screen popup redesign
* Open permission request in notification instead of tab
* Remove no longer user locales
* Update permissions unit test mock to accout for change of opts passed to permissions controller
* Lint fix
* Inline broken line svg in permission-page-container-content.component.js for faster loading
* Add back button to second screen on connect flow
* Add xOfY locale and use for the page count in the connect flow
* Lint fix for svgs permission-page-container-content.component.js
* Fix rebase error
* Lint fix
* Clean up styles on the connect-screen-into-popup branch
* Use closeCurrentWindow to close window on cancel when in full screen connect flow
* Handle errors in rejectPermissionsRequest
* Full screen styles for connect flow
* Lint fixed in permissions-connect and actions.js
* Redirect screen now shows metamask icon instead of users identicon
* Fix subtitle spacing in permissions-connect-header'
* Use window.close instead of closeCurrentWindow() in cancelPermissionsRequest
* Use permissions-connect-header__subtitle in permissions-connect-header.component
The sidebar used to speed up a transaction while it's pending or after
it has failed currently allows editing the gas limit, but that new
limit is ignored. This is especially problematic for transactions that
failed due to a low gas limit, as the problem becomes impossible to fix
by retrying.
The gas limit specified by the user is now used in the speed up
transaction.
Fixes#8156Fixes#7977
Implement `eth_decrypt` and `eth_getEncryptionPublicKey`. This allows decryption backed by the user's private key. The message decryption uses a confirmation flow similar to the messaging signing flow, where the message to be decrypted is also able to be decrypted inline for the user to read directly before confirming.
This was done to reduce the number of direct dependencies we have. It
should be functionally equivalent. The bundle size should not change,
as we use `clone` as a transitive dependency in a number of places.
Update accounts permission history on accountsChanged
Create PermissionsLogController
Fix permissions activity log pruning
Add selectors, background hooks for better UX
Make selected account the first account returned
Use enums for store keys in log controller
Add last selected address history to PreferencesController
* Specify type before parameter name
Various JSDoc `@param` entries were specified as `name {type}` rather
than `{type} name`.
A couple of `@return` entries have been given types as well.
* Use JSDoc optional syntax rather than Closure syntax
* Use @returns rather than @return
* Use consistent built-in type capitalization
Primitive types are lower-case, and Object is upper-case.
* Separate param/return description with a dash
* Remove unused onboarding stream
* Pass `sender` through to `setupProviderEngine`
The Port `sender` has been passed down a few more layers. This allows
us to get more information from the sender deeper in the stack, but
also simplifies things a bit as well. For example, now the "fake"
URL object with the `metamask` hostname is no longer needed.
* Create onboarding middleware
This middleware intercepts `wallet_registerOnboarding` RPC messages. It
will register the sender as an oboarding initiator if possible, and
otherwise ignores the message.
The connect route now takes a route parameter: the permissions request
id. This id is set whenever the permissions connect screen is opened,
ensuring that that tab is for that specific request alone.
This makes handling of multiple permissions requests a bit more
intuitive. Previously whenever opening multiple permissions requests,
the first one would be shown on each successive tab, whereas you
would expect each tab to show the request that prompted the tab to
open. Users may now address permissions request in whichever order
they'd like to, rather than being forced to deal with them
chronologically.
Attempts to approve or reject a permissions request that is no longer
pending will now emit a warning instead of throwing an exception.
I _think_ this can happen by clicking 'Submit' on the Permission
Connect screen twice, though I've been unable to reproduce that. I know
that it can be done if using multiple windows though. While it is
possible we have a UI bug somewhere (e.g. maybe we're not preventing
'Submit' from being clicked twice), I don't think it's possible to
eliminate the chance of this happening altogether, so we'd best prepare
for it.
