Lit virtualizers stop updating after their host is reattached #1354

Describe the bug

Remove a rendered Lit virtualizer host with no pending update and insert the same element again. Scrolling no longer updates the virtual rows and leaves a blank viewport beyond the initially rendered rows. This affects moving an existing custom element between containers without changing its reactive properties.

Your minimal, reproducible example

The existing Lit fixed example, using the steps below.

Steps to reproduce

1. Check out the linked revision, use Node 24.8.0 and pnpm 11.9.0, and run pnpm install --frozen-lockfile.
2. Run pnpm --filter @tanstack/virtual-core build, pnpm --filter @tanstack/lit-virtual build, and pnpm --filter tanstack-lit-virtual-example-fixed dev.
3. Open the local example, wait for the first list to render, then run this in the browser console:

const host = document.querySelector('my-app').shadowRoot.querySelector('row-virtualizer-fixed')
const parent = host.parentNode
const next = host.nextSibling
host.remove()
parent.insertBefore(host, next)
requestAnimationFrame(() => requestAnimationFrame(() => {
  host.shadowRoot.querySelector('.scroll-container').scrollTop = 3500
}))

4. The scroll offset reaches 3500, but the list keeps rows 0–10 and the viewport is blank. Before removing the host, the same scroll operation renders rows around index 100.

Expected behavior

A reattached host resumes observing its scroll container and renders the rows at the current scroll offset.

How often does this bug happen?

Every time with the steps above.

Screenshots or Videos

The reproduction above shows the blank viewport without additional setup.

Platform

macOS, Chromium (Playwright browser build 1228).

tanstack-virtual version

@tanstack/lit-virtual 3.15.1; @tanstack/virtual-core 3.19.9.

TypeScript version

5.9.3.

Additional context

The element and window controllers share the connection lifecycle. The same element can be reattached repeatedly without changing any reactive property.

Terms & Code of Conduct

• I agree to follow this project's Code of Conduct
• I understand that if my bug cannot be reliable reproduced in a debuggable environment, it will probably not be fixed and this issue may even be closed.