1 Commits (fix-derived-leak-on-throw)

Author	SHA1	Message	Date
Nic Polumeyv	a6560bbe08	fix: don't resurrect outroing elements when an ancestor block is paused and resumed (#18431) ... Fixes #15604 Given two nested blocks that both transition: ```svelte {#if fetching} <p>loading</p> {:else} <div transition:fade> {#if shown} <div class="red" transition:fade|global>red square</div> {/if} </div> {/if} ``` and this sequence, where each step happens before the previous fade finished: ```js shown = false; // red square starts fading out fetching = true; // outer block starts fading out too fetching = false; // 50ms later ``` the red square should finish fading out and be removed, since `shown` is still false. Instead it fades back in and stays on screen: resuming the outer block walks the whole subtree, clears `INERT` on every effect and plays `in()` on every transition it finds — including the inner block's, so the square's outro is aborted and the removal callback waiting on it never runs. The inner block has no reason to re-run on its own, `shown` never changed again. The root issue is that `INERT` records no ownership — it can't distinguish "paused by the ancestor currently being resumed" (revive) from "paused by its own block for its own reasons" (leave alone). The pause side already has this restraint: `pause_children` refuses to touch a subtree that is already `INERT`. The resume side had nothing to check. This PR marks the one effect `pause_effect` was actually called on — the root of the paused subtree — with a `PAUSED` flag, and gives resume the same restraint: ```js function resume_children(effect, local) { if ((effect.f & PAUSED) !== 0) return; ``` so a resume can only ever undo its own pause; the flag is only cleared by `resume_effect` on that exact effect. If `shown` flips back to true while the outer block is paused, this still works: the inner block effect carries no `PAUSED` itself, so it is resumed and rescheduled, re-evaluates its condition and revives its own branch.	4 days ago