Closed craxal closed 1 week ago
A solution will require more careful management of a webview's lifecycle. Several details that need to be considered are:
After more investigation, I don't think the previously mentioned solution is good enough. The problem seems to be inherent with explorers trying to close themselves. The crux of the problem is that the close()
panel API immediately removes the <webview>
element from the DOM, which destroys its corresponding view model and renderer process (including the explorer and host). But because the request to close came from the explorer itself, it doesn't get a chance to respond.
To solve this problem we can do the following:
<webview>
elements immediately. Rather, it sends a "close" lifecycle event to the <webview>
element to signal that it needs to clean up.<webview>
receives this event, it should refuse new requests and resolve open requests by waiting for responses. It could choose to timeout on open requests.<webview>
sends a message back to the parent process to signal that it is done cleaning up.<webview>
.
PR 554808 exposed a bug related to closing tabs. Specifically, a call to raise the
blob-container.close
event never returns. Thus, any code following an awaited call won't be executed.The underlying problem is due to the
WebviewProxy
disposing of a webview while it is trying to fulfill a request. A disposed webview cannot send a response, which results in a function call that never returns, as illustrated in this (simplified) diagram:See #7976, #7989.