Skip to content

Comments

Wait for body to be replaced before caching snapshot when <head> changes#1494

Open
janko wants to merge 1 commit intohotwired:mainfrom
janko:fix-race-condition-when-head-changes
Open

Wait for body to be replaced before caching snapshot when <head> changes#1494
janko wants to merge 1 commit intohotwired:mainfrom
janko:fix-race-condition-when-head-changes

Conversation

@janko
Copy link

@janko janko commented Feb 2, 2026

When navigating to a page with new <head> children, the body replacement will be delayed by evaluating the new stylesheet/script elements.

In Stimulus context, this means any controller disconnect() callbacks will be delayed as well. Because there is currently no waiting for the body to be replaced before capturing a snapshot of the previous page, the disconnect callbacks might not have finished in time.

This can result in Turbo including dynamicaly created UI components in the page snapshot that didn't have time to tear down. On restoration visit, Turbo will load the cached snapshot together with the UI components, and then Stimulus connect() callbacks will create them again, resulting in duplicated UI components.

We can mitigate this by waiting for the new page to render before capturing the snapshot – i.e. body to finish replacing – ensuring any disconnect() callbacks will have finished by then.

Fixes #1397

…anges

When navigating to a page with new `<head>` children, the body replacement will be delayed by evaluating the new stylesheet/script elements.

In Stimulus context, this means any controller `disconnect()` callbacks will be delayed as well. Because there is currently no waiting for the body to be replaced before capturing a snapshot of the previous page, the disconnect callbacks might not have finished in time.

This can result in Turbo including dynamicaly created UI components in the page snapshot that didn't have time to tear down. On restoration visit, Turbo will load the cached snapshot together with the UI components, and then Stimulus `connect()` callbacks will create them again, resulting in duplicated UI components.

We can mitigate this by waiting for the new page to render before capturing the snapshot – i.e. body to finish replacing – ensuring any `disconnect()` callbacks will have finished by then.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Development

Successfully merging this pull request may close these issues.

Cache preparations don't work when restoring page after <head> changed

1 participant