onDestroy not called for nested component removed during parent nodes exit transition

[Tharit]

Describe the bug

Components are not destroyed when they are removed from their parent node while that node is currently running its exit transition.

Example: I have a component in a div that has a fade transition, and I remove the component while that div is fading out. The component is not destroyed correctly. It is gone from the DOM, but still "alive" (store subscriptions not closed, onDestroy not called, etc).

To Reproduce

I have created a small REPL example that reproduces the issue.

Note how the console only logs the onDestroy call for the Outer component, but NOT the inner component when you click on the "Close" button.
If you remove "transition:fade" in App.svelte:9 then everything works correctly.

https://svelte.dev/repl/eff9e77c7d5c41059616211e46f3f021?version=3.24.1

The example is a bit artificial of course. In our actual application we have a lot of stores subscribed to realtime updates via websocket. It can frequently happen that you switch/navigate between different content (using transitions) and an update just happens to arrive for the "old" content while the transition is active.

Expected behavior
onDestroy should be called / component should be destroyed when using transitions.

Information about your Svelte project:

• Your browser and the version: Chrome 84.0.4147.125 (Official Build) (64-bit)

• Your operating system: OSX 10.15.5

• Svelte version: 3.24.1

Severity

Now that I managed to trace down the cause of this issue it is not that severe, as it's easy to work around; it just blocks us from using transitions / some third party components that rely on them.
However before I managed to isolate it was extremely frustrating as it appeared as seemingly "random" behaviour with some components not unmounting / resulting in dangling store subscriptions and associated weirdness.

[Tharit]

It seems like the bug is not only triggered if the transition is on the parent; it's enough if the parent is waiting for some child to finish its exit transition.
See another REPL here: https://svelte.dev/repl/9ac8610241a643ec81432f72f3427baa?version=3.24.1
Again, if you remove the transition from the div it works.

[vsych]

+1

[tanhauhau]

I hvn't wrap my head around a fix on this, but from what I observe is that, if the parent starts to be unmount first, then the Inner onDestroy did not get called.

a workaround would be moving the on:close after on:close={() => mode='B'}

<Inner on:close={() => mode='B'} on:close ></Inner>

https://svelte.dev/repl/808a7d0e9f704941abf1ba084b846d74?version=3.24.1

[M1sf3t]

think i've been fighting with this same bug for a few days now. I'm including a screenshot that shows the hide variable being logged as true, then the action running (timer should've been destroyed on true), then the hide variable being set back to undefined, yet the carousel doesn't re-render. The last part doesn't happen consistently, but it happens enough to be troublesome.

https://svelte.dev/repl/ab82d572c40d482c92cc211affbc290d?version=3.24.1

[M1sf3t]

updated that repl so that the carousel actually worked after the first slide. when i moved the "slide" declaration outside of the set interval, the destroy method for the action broke it 🤦‍♂️.

The general problem is still not solved tho, neither the onDestroy method nor the actions destroy method seem to have any affect on the delay timer when the component is hidden with if. To see the latter in the repl, remove comments, slide declr. & onDestroy method and declare slide inside of interval.

I think I've managed a workaround using svelte component instead of the if statement, so far it seems to be working, tho at the moment there's occasionally a jump when it renders. you can see the workaround here --> https://svelte.dev/repl/40741fc76d52405688e8705ec26c254c?version=3.24.1

[pushkine]

duplicate of #4696 and #4064, kinda explained but not fixed in #4699

The internal function transition_out is used in two ways, one is to start outro, the other is to start outro and schedule a destroy after the transition group has outroed

svelte/src/runtime/internal/transitions.ts

Lines 56 to 62 in 8adb474

	outros.c.push(() => {
	outroing.delete(block);
	if (callback) {
	if (detach) block.d(1);
	callback();
	}
	});

Calling transition_out on a block adds it to a Set, so further transition_out calls on the same block are ignored

svelte/src/runtime/internal/transitions.ts

Lines 51 to 53 in 8adb474

	export function transition_out(block, local: 0 | 1, detach: 0 | 1, callback) {
	if (block && block.o) {
	if (outroing.has(block)) return;

From there you can deduce that any transition_out used in the first way makes it so that any destroy scheduled through the second way gets ignored, that is what happens in all of the above when an if_block is outroed by its parent's .o() then outro & destroy scheduled by its parent's .p()

[M1sf3t]

that makes sense but why does it work differently with keyed each and svelte:component? in the last repl I posted, the transition continues to fade out but toggling the svelte component to rerender the carousel at the right moment doesn't break the carousel like it did with the if in the first repl. At least I haven't been able to break it so far anyway.

Same with each, when i first started on the carousel I felt like keyed each would be too much for just one image so I went with if and found that when not timed correctly (using interval/onMount rather than use/timeout at that point, needed to be somewhat around one second after the out ended) the same image would just reappear over and over again.

The latter may not be the exact situation, but it felt like it was a similar issue. Easy enough to fix when it was just that, but as I got to playing with different ways to load the images and swap them out with my spinner, it created more and more problems so I finally just swapped the if out with the keyed each and moved on.

[the0neWhoKnocks]

Not sure if it's the same thing, but onDestroy isn't firing for me when I use custom in/out transitions. This may be by design, and if that's the case, it may be helpful if the example is updated to call that out.

props:

in:toggleDialog="{{ dir: 'in', start: 70 }}"
out:toggleDialog="{{ start: 50 }}"

What I ended up doing within toggleDialog

if (dir !== 'in' && t === 0 && onClose) onClose();

---

Edit: I discovered that while working with some stores, that the above didn't actually work. I didn't fully understand what was actually occurring when a custom transition function was called (it builds out a static CSS animation); I was thinking it was calling that method during the animation steps, lesson learned.

Here's the current solution I'm using:

props

in:toggleDialog="{{ dir: 'in', start: 70 }}"
out:toggleDialog="{{ start: 50 }}"
on:outroend={handleCloseEnd}

handler

function handleCloseEnd() {
  dialogOpen.set(false); // global store to ensure multiple dialogs aren't open
}

[braebo]

old comment

I currently have a project with lots of transitions and noticed this bug randomly occurs when navigating between pages. There will randomly be invisible dom nodes stacking up on pages, pushing the current page content way down. It more or less renders the website unusable.

What is the recommended fix currently? I noticed @tanhauhau and @the0neWhoKnocks's fixes might help. Considering the amount of elements, it will be non-trivial to wrap every single component in it's own {#if} block and trigger it on:outroend (if I understand the fix correctly). But if that's the best way, so be it. Project deadline is coming up 😅

I think this issue should get the bug label, because it's pretty devastating to large projects with transitions.

PS: I found myself in the situation when we had to introduce an extra store to handle state on page transitions- which I assume is what caused all elements with transitions in the project to start showing this bug.

Edit: It appears my issue was actually caused by the uncaught error mentioned in #6037.

It's a bit early to know for sure, but changing line 203 in svelte/internal/index.js as mentioned in that issue seems to have fixed things.

- node.parentNode.removeChild(node);
+ if (node.parentNode) node.parentNode.removeChild(node);

[stale]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

[simonwiles]

This is still a big problem and should not be closed, imo.