I am not very deep into the browser side of the code, @Tyriar has more insights here. Still I think it is not possible to move an already DOM-attached terminal to another DOM node by calling open again.

@Tyriar Do we need an attach/detach cycling for the DOM hooking? It never came to me before, that someone would want to move an existing terminal to another DOM node, so this might be just a wild idea of limited use. Loosely linked or more generalized to this would be support of a copy ctor like const term2 = new Terminal(term1), where the new terminal could start over in DOM-detached mode, but has inherited all VT-related settings/data. This has some intersections with the serialize addon, so might not be worth either the trouble.

+1 to this. I have the same use case in our work application which has multiple kinds of terminals in various drawers that can be opened/closed at will.

Calling open multiple times was never really supported that well and I think can be a little finicky, but it definitely does work as that's what VS Code does in order to move the terminal around the workbench.

If we can get a repro case without React it will be a lot more clear how to action this.

Here's a little codesandbox (no React). The Open button mounts the terminal instance to the DOM and writes a line. The Replace button removes the DOM and replaces it with a new div. Running Open again results in no line being written.

https://codesandbox.io/p/sandbox/fz8kq2?file=%2Fsrc%2Findex.ts

FWIW, my workaround for now has been to register when the terminal mount DOM has been changed and/or removed. If so, I dispose the terminal instance and any addons. The next time that terminal's container mounts, I re-initiate the instances and run open from a fresh terminal instance.

Just wanted to mention that .open() works fine for [email protected]

Can't seem to debug in the code sandbox, but it's likely it's hitting this:

Maybe this.element?.isConnected needs to be checked too?

Can't seem to debug in the code sandbox, but it's likely it's hitting this:

xterm.js/src/browser/CoreBrowserTerminal.ts

Lines 402 to 409 in 41e8ae3

	// If the terminal is already opened
	if (this.element?.ownerDocument.defaultView && this._coreBrowserService) {
	// Adjust the window if needed
	if (this.element.ownerDocument.defaultView !== this._coreBrowserService.window) {
	this._coreBrowserService.window = this.element.ownerDocument.defaultView;
	}
	return;
	}

Maybe this.element?.isConnected needs to be checked too?

@Tyriar I have tested locally for my use case, and like you suggested, adding this.element?.isConnected makes things work! Is there any other deep concerns? I have created a naive PR for the fix #5253