-
Notifications
You must be signed in to change notification settings - Fork 5k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Handle one specific permissions request per tab #7620
Conversation
Builds ready [97b5093]
|
const permissionsRequests = getPermissionsRequests(state) | ||
|
||
const permissionsRequest = permissionsRequests | ||
.find(permissionsRequest => permissionsRequest.metadata.id === permissionsRequestId) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Not sure if we can assume that permissionsRequest.metadata
will always be an object
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think we can. This is the only place requests are added: https://github.com/MetaMask/rpc-cap/blob/master/index.ts#L817
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yeah, that rpc-cap
metadata has not been a problem historically. Site/domain metadata in the permissions middleware has caused trouble by not existing (ごめんなさい 🙇).
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Reviewed and left one comment. Looks good otherwise.
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.
97b5093
to
5f8ceca
Compare
Builds ready [5f8ceca]
|
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.