`<Suspense>` panic only in release mode, only on Firefox

[tannerntannern]

I'm following the bug report template for discoverability, but please note that I also created a minimum reproducible example repository here: https://github.com/tannerntannern/leptos-firefox-bug-reprex

Describe the bug

<Suspense> within <details> element causes panic only in release mode, and only on Firefox (latest version). The <details> element might not be the root cause, but it's unclear to me what is.

Code snippets

Dependencies

# common
leptos = { version = "0.8.15", features = ["tracing"] }

# frontend only
console_error_panic_hook = { version = "0.1.7", optional = true }
wasm-bindgen = { version = "=0.2.106", optional = true }

# backend only
axum = { version = "0.8.8", optional = true }
leptos_axum = { version = "0.8.7", features = ["tracing"], optional = true }
tokio = { version = "1", features = ["full"], optional = true }

App component

#[component]
pub fn App() -> impl IntoView {
    let data_resource = OnceResource::new(get_data());
    view! {
        <details open>
            <summary>"Server Data"</summary>
            <Suspense fallback=move || view! { <div>"Loading data"</div> }>
                {move || Suspend::new(async move {
                    let data = data_resource.await.unwrap();
                    view! {
                        "Data: "{data}
                    }
                })}
            </Suspense>
        </details>
    }
}

#[server]
async fn get_data() -> Result<String, ServerFnError> {
    Ok("abc123".to_string())
}

To Reproduce

1. Install cargo-leptos version 0.3.2
2. Run cargo leptos watch --release (could not reproduce in debug mode)
3. Open the app in Firefox for MacOS (tested on latest version; could not reproduce in Chrome or Safari)
4. Observe following error in the console (behavior is not consistent, might need to refresh a few times)

Error details

You should see something to the effect of

panicked at /Users/tnielsen/.cargo/registry/src/index.crates.io-1949cf8c6b5b557f/tachys-0.2.11/src/hydration.rs:227:9:
internal error: entered unreachable code
...

Screenshots

Next Steps

• I will make a PR
• I would like to make a PR, but need help getting started
• I want someone else to take the time to fix this
• This is a low priority for me and is just shared for your information

Additional context

I can make any of the following changes in app.rs and the error goes away:

• Change the <details> element to a <div>
• Remove the outer <details> element entirely
• Change the Suspense fallback to move || "Loading data" (from move || view! { <div>"Loading data"</div> })

Also mentioned above, but I cannot reproduce in any browser except Firefox. I can only reproduce in release mode.

[gbj]

The debug vs. release mode piece of this is almost certainly component erasure vs. not -- you could check if you can reproduce it in debug mode with disable-erase-components = true in the leptos config section of your Cargo.toml.

[tannerntannern]

Thanks for the suggestion @gbj. Unfortunately I'm still only able to reproduce in release mode, whether disable-erase-components = true is set or not

[gbj]

Odd. I can definitely reproduce it in debug mode in Firefox with only the patch below. I can't reproduce in Chrome or Safari.

It appears to be a bug in Firefox's TreeWalker behavior to me. At least, if I disable WASM in Chrome and I disable it in Firefox, I see the following DOM structure in Chrome when I load the page:

<details open="">
  <summary>Server Data</summary>
  Data:
  <!---->
  abc123
</details>

in Firefox, I see

<details open="">
  <summary>Server Data</summary>
  <!--s-1-o-->
  <div>Loading data</div>
  Data:
  <!---->
  abc123
</details>

This means that the Susense-replacement JS that is sent in a <script> tag from the server is producing a different outcome in FF than it is in Chrome or Safari. The FF output is incorrect and is what causes the bug; the Chrome/Safari output is correct and hydrates correctly.

If I replace <details> with a <div> it works correctly in FF, which suggests that this is an FF-specific bug with document tree walkers and the children of the <details> element specifically. I haven't had time to dig in more.