-
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
Ensure that external domains can only open one tab at once #8147
Conversation
app/scripts/platforms/extension.js
Outdated
|
||
class ExtensionPlatform { | ||
|
||
constructor () { | ||
|
||
if (extension.tabs) { |
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 had to add this conditional to get the integration tests to pass.
If anyone can tell me how to mock this value, please let me know, and I'll do so.
Builds ready [ddca6b1]
Page Load Metrics (587 ± 55 ms)
|
Builds ready [374f97f]
Page Load Metrics (584 ± 42 ms)
|
Hmm.... how would this handle the case where the user used a tab opened by us to navigate away? 🤔 e.g. if I used the connect flow tab to google something. I think that'd just break any subsequent interactions with that dapp. |
Maybe we could use There is a current bug with |
We should definitely resolve the If the user navigates to a different site in a MetaMask UI tab, that ought to destroy that UI instance, and cause stream teardowns to fire. Could we get the Not sure how it would work if the user goes back to the MetaMask UI in such a tab. Would that be problematic? |
Yep! I'm fairly certain we can anyway. The
I think that would be fine - if the user navigates back, we can treat it as a normal MetaMask fullscreen tab. By that time the connection to the dapp will have been severed, and the dapp can still initiate new screens. |
^ I'm just gonna mark this as DONOTMERGE for now because I keep opening this PR to review, forgetting that it has changes pending 🤦♂️ |
This should be unblocked now that #8314 has been merged |
Builds ready [3c01867]
Page Load Metrics (646 ± 15 ms)
|
|
||
/** | ||
* Set up listeners for managing tab creation. | ||
*/ | ||
function setupBrowserListeners () { | ||
extension.tabs.onRemoved.addListener(handleTabRemoved) | ||
} |
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.
Given the handling in endOfStream
above (L390), do we even need this?
@Gudahtt rebased and updated per previous discussions on this PR. One open question re: a possible simplification. |
Builds ready [76be4db]
Page Load Metrics (587 ± 56 ms)
|
Builds ready [50ad55f]
|
Builds ready [154d500]
|
Builds ready [d63acc7]
|
We can come back to this at some point |
Summary
requestUserApproval
MetamaskTabsIDs
toMetamaskTabIds
, for great benefit to consistency and styleDetails
The
requestUserApproval
function for permissions requests opens the extension in a new browser tab. Currently, there is no limit to the number of tabs that an external origin can open by submitting permissions requests.This PR establishes a "tab creation history" to track which origins have (effectively) created an open tab. If an origin already has an open tab and makes a new tab-creating request, no new tab will be created. When the tab created by an origin is closed, the origin is removed from the tab creation history, and can once again create a new tab.
The need for this was exposed when I left a faulty test dapp open in Chrome, and it spawned 10 tabs, like so:
Misc.
The behavior of that test dapps still creates, over time, an unbounded number of pending permission requests for the same origin, and we should consider implementing a similar logic for permissions requests (e.g., only one pending request at a time), but that would be a separate PR. For that, see: #8148