Transitions causing error thrown: Cannot read properties of null (reading 'p')

[arggh]

Describe the bug

I'm aware a REPL would be helpful, but I couldn't reproduce the issue in the REPL, even though trying for several hours. So, posting this here with the best details I can give:

A fade-transition in a deeply nested component caused Uncaught (in promise) TypeError: Cannot read properties of null (reading 'p') when attempting to navigate to another page on our app.

The error-causing-transition is inside a Card-component, repeated within a {#each} block inside a larger Page-component.

Relevant part of the Card -component:

<div class="carousel">
    <div class="nav">
      <button class="prev" on:click={(e) => e.preventDefault()}>
        {#if $index > 0}
          <div class="nav-btn" transition:fade={{ duration: 200 }}> <!-- <<THESE TRANSITIONS -->
            <slot name="prev" />
          </div>
        {/if}
      </button>
      <button class="next" on:click={(e) => e.preventDefault()}>
        {#if $index < maxIndex}
          <div class="nav-btn" transition:fade={{ duration: 200 }}> <!-- <<THESE TRANSITIONS -->
            <slot name="next" />
          </div>
        {/if}
      </button>
    </div>
...

The stacktrace wasn't very helpful.

After disabling source maps I could see the exact line throwing, which originated from the Page-component, more specifically from a very simple <div><slot/></div> type of component used on the Page:

function create_default_slot_13
....
   const block = {
   ....
   p: function update(ctx, dirty) {
      	let previous_block_index = current_block_type_index;
      	current_block_type_index = select_block_type_1(ctx, dirty);

      	if (current_block_type_index === previous_block_index) {
      		if (~current_block_type_index) {
      			if_blocks[current_block_type_index].p(ctx, dirty); // <<< trying to read `p` from null
      		}

If I remove the transitions from the Card-component, the problem disappears, so we can work around it.

Sorry for the crappy bug report. I'll keep trying to reproduce the problem in the REPL, but it seems challenging.

Reproduction

Not available, yet.

Logs

No response

System Info

Svelte 3.53.1, Chrome 107

Severity

annoyance

[Prinzhorn]

Are you using any third party Svelte components? They need to specify a svelte entrypoint in their package.json (and your bundler needs to be configured accordingly to respect said entry point, e.g. mainFields in esbuild). Otherwise errors like yours appear because of two conflicting Svelte "instances" in parallel. Because you are essentially importing a compiled component and not the Svelte file. See discussion in #3165

[arggh]

Only one, svelte-loadable. I'm aware of the "multiple Svelte instances" -problem and even have a script written for our specific environment that checks there's only one "instance" of Svelte installed inside the repo folder. This problem seems to happen only with this one specific component: if it was caused by multiple "instances" of Svelte, I'd assume there would be other symptoms as well, in other components & other parts of our (rather large) app, right?

[Prinzhorn]

if it was caused by multiple "instances" of Svelte, I'd assume there would be other symptoms as well, in other components & other parts of our (rather large) app, right?

I don't know, it was just a guess. Because in #3165 the symptoms only occurred when using transitions, that's why it immediately came to mind. And the fact that you cannot turn it into a REPL might be a sign that it's related to some sort of bundling issue. But it doesn't have to be, it might just as well be an ordinary bug.

[dummdidumm]

Closing due to lack of reproduction - this may have been fixed in Svelte 5

[RoryDuncan]

TL;DR: Confirming that this is likely resolved in svelte 5.

I have been battling this for the past week, and my attempts to reproduce weren't completely successful but figured I'd share my learnings for the next person to come along.

The app I'm building has websocket connections, plus async calls and abort-controller fetches which updates stores and their derived stores. All powering a UI similar to Google Sheets, we'll say.

• I spent time debugging and breakpointing svelte's runtime code
• I spent some time confirming my dependencies were using the svelte, rather than the compiled component.
• Oddly, I could only reproduce on environments where network requests were <100ms. Delay "fixed it".

I eventually ran out of time to investigate and removed all transitions within {#each} blocks. This fixed it (foreseeably).

Attempt to replicate in REPL

I did try to configure a simple setup, but I can't replicate the thrown error.
On a hunch, I did add a Portal component to see how much it wreaks havoc on sveltes bindings.

https://svelte.dev/playground/2e06c1d6676540678bbb28f76b681c11?version=4.2.12

If you hammer the "Run Many" button you can observe that transition states get all messed up.
Additionally, if you hammer it enough you can observe it will generate a new red box. It appears svelte lost track of the previous node within the portal or something.

Now, the same code in svelte5 (not using runes):

https://svelte.dev/playground/2e06c1d6676540678bbb28f76b681c11?version=5.2.0

You can observe that it is less janky and ends up not having any observable issues. Props to svelte 5 :)