[Bug] WSI viewport cannot be re-enabled

[sgielen]

Describe the Bug

I've noticed that if the WSI viewport is created using enableElement, then future enableElement (even with a corresponding disableElement in between) breaks the viewport.

Steps to Reproduce

In the WSI example, just after renderingEngine.enableElement(viewportInput);, add these lines:

  renderingEngine.disableElement(viewportId);
  renderingEngine.enableElement(viewportInput);

Now, run the example using yarn example -- wsi.

The current behavior

The viewport no longer shows an image:

The expected behavior

A disableElement then enableElement with the same options should be a no-op, so behaviour should be the same as without those additional lines. (Perhaps even without a disableElement a repeated enableElement with the same options should be a no-op, arguably?)

System Information

  System:
    OS: macOS 26.3.1
    CPU: (10) arm64 Apple M1 Pro
    Memory: 191.41 MB / 16.00 GB
    Shell: 5.9 - /bin/zsh
  Binaries:
    Node: 25.2.0 - /opt/homebrew/bin/node
    Yarn: 1.22.22 - /opt/homebrew/bin/yarn
    npm: 11.6.2 - /opt/homebrew/bin/npm
  Browsers:
    Brave Browser: 146.1.88.138
    Chrome: 147.0.7727.55
    Safari: 26.3.1

[linear]

CS-148

[sgielen]

From the fact that the WSIViewport constructor writes "Initial" to the element, before initializing dicom-microscopy-viewer, and the second enableElement results in the "Initial" being visible, I gather an (otherwise unfounded) hypothesis that the second initialization of dicom-microscopy-viewer is either skipped or fails.

Because of this, I was looking into how WSIViewport mounts and unmounts, and also into how dicom-microscopy-viewer expects to mount and unmount. In both cases, mounting is quite obvious, but unmounting isn't. I could find cleanup() on the VolumeImageViewer, but it seems memory-related, not DOM-related.

As far as I can tell from the source code, the RenderingEngine does not tell the Viewport that it's being destroyed, and does not seem to give it a chance to clean up. Perhaps the WSIViewport is an outlier here, where it uses an external library that might require cleanup as well?

[sgielen]

I could look into this further, unless it's already obvious to you what's going on?