[BUG] cannot completely destroy the viewer when switch the pages

[wunderbarr]

Describe the bug
I am using NextJS as frontend and want to render pdb files. The file could be rendered correctly, but when I switch to other page, the following error would occur:

 [.WebGL-0xa280b1f5c00] GL_INVALID_FRAMEBUFFER_OPERATION: Framebuffer is incomplete: Attachment has zero size.)

I am not sure the correct way to dispose/destroy or clean up the viewer, not find any tutorial about that.
To Reproduce
I use the following code to visualize and clean the viewer, but not successful:

const ThreeDmolViewer = ({ pdbData, id }) => {
	const viewerRef = useRef(null);

	useEffect(() => {
		if (viewerRef.current && pdbData) {
			const viewer = window.$3Dmol.createViewer(viewerRef.current, {
				defaultcolors: window.$3Dmol.rasmolElementColors,
			});

			viewer.addModel(pdbData, "pdb");
			viewer.setStyle({}, { cartoon: { color: "spectrum" } });

			viewer.zoomTo();
			viewer.render();

			viewer.spin(true);

			return () => {
				viewer.spin(false);
				viewer.removeAllModels();
				viewer.clear();
				viewer.stopAnimate();
			};
		}
	}, [pdbData]);

	return (
		<div
			id={`3DmolViewer_${id}`}
			style={{ position: "relative", width: "400px", height: "400px" }}
			ref={viewerRef}
		></div>
	);
};

Expected behavior
No warning when switch pages. Namely the viewer could be destroyed.

Desktop (please complete the following information):

• Ubuntu 20.04
• Browser chrome

[dkoes]

The only issue is a warning in the console, correct?

I assume there is a race condition between the canvas being destroyed by the browser and the animation stopping code. Do you have evidence that your clean up code is being run before the DOM tear down and you are still getting this error?

You can check the value of viewer.getRenderer().isLost() when this code is run. If it is true, it is running too late.

[wunderbarr]

The only issue is a warning in the console, correct?

I assume there is a race condition between the canvas being destroyed by the browser and the animation stopping code. Do you have evidence that your clean up code is being run before the DOM tear down and you are still getting this error?

You can check the value of viewer.getRenderer().isLost() when this code is run. If it is true, it is running too late.

Thank you for your feedback. Yes. It's only a warning in the console.
I try to check the value within the useEffect hook, its value is always false. So I'm not sure how to address this warning.

[dkoes]

We'd need to figure out what operation is trying to use the destroyed canvas. I had assumed it was the animation, but if it is disabled then it must be something else (not sure what).

[wunderbarr]

We'd need to figure out what operation is trying to use the destroyed canvas. I had assumed it was the animation, but if it is disabled then it must be something else (not sure what).

I don't know what operations or functions could be used. So I try methods like removeAllModels(), clear() and stopAnimate();
I render pdb file, namely a 3D structure. Not sure whether it belongs to an animation. Don't know how to completely clean up.

[dkoes]

You need to break when the warning is generated and look at the call stack to see what is triggering the warning.

[OreFoX18]

I'm encountering a similar issue. While implementing the viewer in my React application, I'm facing a warning in the console during the component's unmounting phase. Despite spending hours debugging and attempting various solutions, I haven't been able to resolve the problem.

[dkoes]

If you can provide a reproducible, self-contained test case I can look at it.

[jacobfilik]

Probably bad form to comment on a closed issue, but for me the error is raised in the render method:

Uncaught NS_ERROR_NOT_AVAILABLE: render Renderer.ts:903 show GLViewer.ts:325 resize GLViewer.ts:1460 GLViewer GLViewer.ts:695 createViewer GLViewer.ts:4910 <useEffect call in my react component>

if i break the viewer encapsulation and set:
viewer.scene = null;

this triggers the early return in GLViewer show stopping the error, but I don't know how to properly stop this render loop happening when cleaning up a component.

[dkoes]

Not bad form, it is only closed because it went a year without any followup. If you can provide a reproducible, self-contained test case I will look into it.

[jacobfilik]

https://codesandbox.io/p/sandbox/wt4gl5

Might be browser specific (i guess possibly due to when component is actually disposed), switching between the two links in the demo kills the app in firefox (128.10.1) but works ok in Chrome. Setting viewer.scene = null when unmounting component stops the issue (but that is a private variable). Think its just a race condition between the component being cleaned up and the render loop. Might just need a flag that can be set in unmount that stops the render (similar to setting the scene to null).

[silicon625]

Hi @dkoes , I encountered the same warning when developing a vue application. I believe it was caused by event listeners and resources not being cleaned up when the viewer is destroyed or the component unmounted.

window.addEventListener("resize", this.resize.bind(this)); (GLViewer.ts row:730) remains active even after the viewer is removed.
This leads to problems when reusing or remounting the viewer.

It would be great if 3Dmol.js could expose a cleanup API, like:
viewer.destroy();

[silicon625]

Hi @dkoes, I believe this issue is still unresolved. Would it be possible to reopen this issue?
I suggest adding a cleanup API to various kind of event listener added by 3dmol.js (especally resize listener).
In frontend frameworks like Vue, it's common to dynamically add and remove HTML elements. However, if an event listener is not properly unbound when the element is hidden or removed, it may continue to run in the background and lead to unexpected behavior. This might be what’s happening in this case.