Moving an Astro Island while it's hydrating causes slots in templates to vanish

[fragglebob]

Astro Info

Astro                    v5.12.8
Node                     v22.11.0
System                   macOS (arm64)
Package Manager          npm
Output                   static
Adapter                  none
Integrations             @astrojs/react

If this issue only occurs in one browser, which browser is a problem?

Seen in Safari based browsers

Describe the Bug

When an Astro Island is moved in the DOM, it seems the connectedCallback can get called again (in some browsers anyway), causing the start method to also run again, which results in hydrate method getting fired a second time.

It seems there is a bit of a race condition, where the second call can happen before the ssr attribute is removed from the island during that first call to hydrate. The second call to hydrate ends up updating the framework component with new props and slots, because the ssr attribute remains. During this second pass, no slots that ended up in templates are there anymore, as they were removed during the first pass.

This results in the framework component losing those slots.

I have only tested with the React integration. This also doesn't happen exactly the same every time, but seems pretty repeatable in the minimal reproduction for me.

What's the expected result?

I'd expect the slots that ended up in templates to remain passed to the framework component, even after they are removed from the DOM.

Link to Minimal Reproducible Example

https://stackblitz.com/edit/github-cfalhuk1?file=src%2Fpages%2Findex.astro

Participation

• I am willing to submit a pull request for this issue.

[ascorbic]

I'm inclined to say that this is behaving is expected. connectedCallback is called whenever a custom element is added to the DOM, which is what you're doing here. Doing that while it is in the process of running is bound to cause race conditions. Astro could probably handle it more gracefully, but the better solution is to not manipulate the DOM while it's in the process of hydrating.

[fragglebob]

Yes, a lot of it is as I would expect too. As it's exactly how connectedCallback works.

I played around with a solution that moved the checking of the ssr attribute out of each of the integrations into hydrate(), where the attribute was removed earlier, which seemed to solve it. Happy to raise it as a PR.

I did end up avoiding manipulation of the DOM as the workaround, once I worked out that was the cause.

[ascorbic]

A PR would be good. I can't guarantee it would get merged, because others who are closer to that part of the code may know reasons that it's not a good idea, but it could be a starting point for testing it