Skip to content

Conversation

mikesposito
Copy link
Member

The LedgerBridgeIframe class gets initialized through the init method. However, if the iframe that is set up during this method call fails for some reason, the promise returned by init will never resolve/reject.

Downstream, this prevents the KeyringController mutex from being ever released, causing deadlocks at unlock time.

The solution applied in this PR is to make the iframe set up during the init call optional, and then later reattempting it whenever another method needs the iframe and finds it uninitialized

@mikesposito mikesposito requested a review from a team as a code owner January 17, 2025 17:59
Comment on lines 322 to 328
this.iframe.onerror = (): void => {
if (this.iframe) {
document.head.removeChild(this.iframe);
}
this.iframeLoaded = false;
reject(new Error('Failed to load iframe'));
};
Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'm not sure that this is actually needed, since the timeout would kick in anyway, but seemed useful

}
// If the iframe isn't loaded yet, the initialization is reattempted
if (!this.iframeLoaded) {
await this.#init();
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Hmm, we certainly wouldn't want to trigger the creation of the iframe multiple times. Perhaps we could store a pending initialization as a promise somewhere, to prevent concurrent initialization attempts?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Good point. I added a deferred promise in fb00879

@mikesposito
Copy link
Member Author

@metamaskbot publish-preview

Copy link

Preview builds have been published. See these instructions (from the core monorepo) for more information about preview builds.

Expand for full list of packages and versions.
{
  "@metamask-previews/keyring-api": "17.2.1-1fb8dc3",
  "@metamask-previews/eth-hd-keyring": "12.0.0-1fb8dc3",
  "@metamask-previews/eth-ledger-bridge-keyring": "10.0.0-1fb8dc3",
  "@metamask-previews/eth-simple-keyring": "10.0.0-1fb8dc3",
  "@metamask-previews/eth-trezor-keyring": "8.0.0-1fb8dc3",
  "@metamask-previews/keyring-internal-api": "6.0.0-1fb8dc3",
  "@metamask-previews/keyring-internal-snap-client": "4.0.1-1fb8dc3",
  "@metamask-previews/eth-snap-keyring": "12.0.0-1fb8dc3",
  "@metamask-previews/keyring-snap-client": "4.0.1-1fb8dc3",
  "@metamask-previews/keyring-snap-sdk": "3.1.0-1fb8dc3",
  "@metamask-previews/keyring-utils": "3.0.0-1fb8dc3"
}

@mikesposito
Copy link
Member Author

After some testing with preview builds, it appears that onload is not a reliable source to resolve the iframe initialization, as it is also called when the iframe load is errored. The changes in this PR are still valid against scenarios of slow connection, as the timeout would kick in before onload, but not if the page responds with an error. Additionally, after the iframe is loaded with an error, the rest of the methods will try to send messages to the iframe that will never be resolved, creating other scenarios of infinite loading.

A solution could be having a message handler on the bridge to check if the connection is alive (i.e. the iframe is initialized for real)

Copy link

This PR is marked as stale because it has been open for 60 days with no activity. Please remove the stale label or leave a comment, or it will be closed in 14 days.

@github-actions github-actions bot added the Stale label May 12, 2025
Copy link

This PR was closed due to no follow-up activity in the last 14 days. Thank you for your contributions.

@github-actions github-actions bot closed this May 26, 2025
@mikesposito
Copy link
Member Author

This PR was discarded in favor of this other solution: #271

@mikesposito mikesposito deleted the mikesposito/init-iframe branch May 27, 2025 14:00
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants