fix: init uses a timeout and other methods reattempt init
#151
Conversation
| this.iframe.onerror = (): void => { | ||
| if (this.iframe) { | ||
| document.head.removeChild(this.iframe); | ||
| } | ||
| this.iframeLoaded = false; | ||
| reject(new Error('Failed to load iframe')); | ||
| }; |
There was a problem hiding this comment.
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(); |
There was a problem hiding this comment.
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?
There was a problem hiding this comment.
Good point. I added a deferred promise in fb00879
|
@metamaskbot publish-preview |
|
Preview builds have been published. See these instructions (from the Expand for full list of packages and versions. |
|
After some testing with preview builds, it appears that 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) |
The
LedgerBridgeIframeclass gets initialized through theinitmethod. However, if the iframe that is set up during this method call fails for some reason, the promise returned byinitwill 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
initcall optional, and then later reattempting it whenever another method needs the iframe and finds it uninitialized