-
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
EIP-1102 updates #6006
EIP-1102 updates #6006
Changes from all commits
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
Original file line number | Diff line number | Diff line change |
---|---|---|
|
@@ -65,9 +65,11 @@ class ExtensionPlatform { | |
} | ||
|
||
sendMessage (message, query = {}) { | ||
extension.tabs.query(query, tabs => { | ||
const id = query.id | ||
delete query.id | ||
extension.tabs.query({ ...query }, tabs => { | ||
tabs.forEach(tab => { | ||
extension.tabs.sendMessage(tab.id, message) | ||
extension.tabs.sendMessage(id || tab.id, message) | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. If the There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Should we be sending a message to tab There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. I feel like a query with multiple properties should hit tabs that satisfy all properties, not just some. This is why we 1) query without the ID, then 2) iterate through the results and further filter by ID. If we detected ID first then bailed, that implies an ID takes precedence over all other query properties. There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Hmm, maybe I don't understand what these APIs are doing well enough. If we call There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Whymarrh's concern made sense to me, and then I tried to word it and understood Paul's point: The tabs.query method does not take an |
||
}) | ||
}) | ||
} | ||
|
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -1,6 +1,6 @@ | ||
MetaMask is beta software. | ||
|
||
When you log in to MetaMask, your current account's address is visible to every new site you visit. This can be used to look up your account balances of Ether and other tokens. | ||
When you log in to MetaMask and approve account access, your current account's address is visible to the site you're currently viewing. This can be used to look up your account balances of Ether and other tokens. | ||
|
||
For your privacy, for now, please sign out of MetaMask when you're done using a site. | ||
For your privacy, take caution when approving account access and sign out of MetaMask when you're done using a site. | ||
|
Original file line number | Diff line number | Diff line change |
---|---|---|
|
@@ -4,8 +4,8 @@ import { approveProviderRequest, rejectProviderRequest } from '../../../actions' | |
|
||
function mapDispatchToProps (dispatch) { | ||
return { | ||
approveProviderRequest: origin => dispatch(approveProviderRequest(origin)), | ||
rejectProviderRequest: origin => dispatch(rejectProviderRequest(origin)), | ||
approveProviderRequest: tabID => dispatch(approveProviderRequest(tabID)), | ||
rejectProviderRequest: tabID => dispatch(rejectProviderRequest(tabID)), | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. I would normally raise a concern about mixing platform-specific details (like tab ID) in with the UI, but I have a proposal for a revised approach to this I want to share with you soon (maybe tomorrow?), that I think will help clean up a lot of this tab management logic. |
||
} | ||
} | ||
|
||
|
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.
Why are we deleting the id from the query here?
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.
Querying tabs worked oddly in Chrome and Firefox. If the
id
was not deleted before querying, no tabs would ever be returned. This is why this roundabout method of sending to a specific ID is used: if anid
is present on aquery
, we cache it, delete it, run the rest of thequery
, then only send the resulting message to tabs matching the cachedid
.