How to properly dispose a VSCode instance when its host iframe is destroyed?

[andresalves01]

We have a product requirement that allows multiple VSCode instances to be active simultaneously within the same browser window. To isolate each Monaco service instance we use iframe as workaround to previous limitations (though we're aware the sandbox approach may now be a viable alternative). The issue is that, when an iframe is destroyed, some memory references don't appear to be released, the most visible symptom being Oniguruma WASM references accumulating across iframe lifecycles. The image below shows two new instantiations of Oniguruma's WASM after destroying the iframe twice.

We believe this is likely a teardown problem on our end rather than a library bug, we're probably missing the correct disposal sequence before removing the iframe from the DOM. Is there a recommended way to fully "disconnect" a VSCode instance before its host iframe is destroyed? We're looking for the right sequence of disposables or lifecycle hooks that would properly release all allocated resources, such as WASM references, workers, event listeners, etc.

My environment setup is:

• "@codingame/monaco-vscode-api": "30.0.1"
• Browser: Chrome v148

Thank you in advance for any help!

[CGNonofr]

I'm trying to understand what your current setup exactly is. Are you providing references to some VSCode objects to the top frame? Or are they sandbox iframes?

If the iframes are sandbox, I don't see how just removing them can leak some memory 🤔 (except because of a browser bug ofc)

[andresalves01]

We aren't using the sandbox feature yet, we just use iframes to enable multiple components to coexist simultaneously on the same page. The architecture is illustrated below.

We have a shared dialog to mount the iframe of multiple buttons. The VSCode service instance is created inside the iframe’s lifecycle and is exposed directly onto its window to allow interaction from the outside context.

The button manager acts as the controller, calling the initialize and close methods on the exposed VscodeInstanceService. This allows us to safely pass outer service references into the iframe, like file system configurations and content management services to sync edits between the VSCode instance and the outer buttons, and manage the connection state.

The problem is that, when we destroy the iframe, whether switching components or navigating pages without a full browser refresh, the tab’s memory usage grows rapidly and memory snapshots show accumulating instances of Oniguruma WASM.

We already have a close hook running during the iframe's destruction cycle, but we're stuck on the best way to completely dispose of the VSCode instance and its underlying services to stop these leaks.

[CGNonofr]

VSCode is not really designed to be "disposed" except by a page reload. If you forward some object to the top frame, I'm afraid there is no obvious answer.

The only way to be sure is to use sandbox iframes, and communicate with it only via postMessages