1
0
mirror of https://github.com/kremalicious/metamask-extension.git synced 2024-11-27 04:46:10 +01:00
Commit Graph

5 Commits

Author SHA1 Message Date
Mark Stacey
63633635ab
Fix order of accounts in eth_accounts response (#8342)
* 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.
2020-04-16 15:20:01 -03:00
Mark Stacey
b2882aa778
Handle account selection on all domains that can view the selection (#8341)
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.
2020-04-16 13:16:53 -03:00
Dan J Miller
d1e078b8de
Connect flow via popup (#8269)
* 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
2020-04-07 16:08:15 -02:30
Erik Marks
2301d9980e
Wait for extension unlock before processing eth_requestAccounts (#8149)
* eth_requestAccounts: wait on unlock

return error on duplicate eth_requestAccounts
add getUnlockPromise mock to permissions unit tests

* only await unlock if already permitted

* add notification badge for wait on unlock

* fixup

* more fixup

* cleanup

* update keyring controller, us its unlock event

* move keyring update unlock logic to unlock event handler

* fix unit tests

* delete onUnlock handler

* fix eth-keyring-controller resolution

* update eth-keyring-controller
2020-03-23 09:25:55 -07:00
Erik Marks
b1d090ac4d
Add permissions controller unit tests (#7969)
* add permissions controller, log, middleware, and restricted method unit tests

* fix permissions-related bugs

* convert permissions log to controller-like class

* add permissions unit test coverage requirements

* update rpc-cap

Co-Authored-By: Whymarrh Whitby <whymarrh.whitby@gmail.com>
Co-Authored-By: Mark Stacey <markjstacey@gmail.com>
2020-03-16 10:13:22 -07:00