Promoted Frame Visits cause `tracked_element_mismatch` reloads #1047

domchristie · 2023-10-26T09:21:36Z

This only impacts main branch builds since #887.

When promoting Frame Visits using data-turbo-action="…", Turbo will reload the page. The turbo:reload event reason is: tracked_element_mismatch. This only appears to be an issue since: #887

/cc @seanpdoyle

The text was updated successfully, but these errors were encountered:

domchristie · 2023-11-24T03:45:35Z

@afcapel I think this is quite a major issue, since it breaks all Turbo Frames visits with a data-turbo-action. Would be good to get fixed before v8 is released

afcapel · 2023-11-24T10:31:56Z

Agreed, let's get it fixed before v8 👍

qinmingyuan · 2023-11-26T09:29:12Z

Any progress at this issue?

seanpdoyle · 2023-11-29T17:54:16Z

@domchristie I'm unable to reproduce this locally in the following test:

test("navigating turbo-frame[data-turbo-action=advance] from within pushes URL state", async ({ page }) => {                                                                                                        
  await page.click("#add-turbo-action-to-frame")                                                                                                                                                                    
  await page.click("#link-frame")                                                                                                                                                                                   
  await nextEventNamed(page, "turbo:frame-load")                                                                                                                                                                    
  await noNextEventNamed(page, "turbo:reload")                                                                                                                                                                      
  await nextEventNamed(page, "turbo:load")                                                                                                                                                                          
  await noNextEventNamed(page, "turbo:reload")                                                                                                                                                                      
                                                                                                                                                                                                                    
  const title = await page.textContent("h1")                                                                                                                                                                        
  const frameTitle = await page.textContent("#frame h2")                                                  
                                                                                                                                                                                                                    
  assert.equal(title, "Frames")                                                                           
  assert.equal(frameTitle, "Frame: Loaded")                                                                                                                                                                         
  assert.equal(pathname(page.url()), "/src/tests/fixtures/frames/frame.html")                                                                                                                                       
})

I've added some assertions related to turbo:reload:

diff --git a/src/tests/functional/frame_tests.js b/src/tests/functional/frame_tests.js
index b090aff..a796e44 100644
--- a/src/tests/functional/frame_tests.js
+++ b/src/tests/functional/frame_tests.js
@@ -642,7 +642,10 @@ test("navigating a frame with a form[method=get] that does not redirect still up
 test("navigating turbo-frame[data-turbo-action=advance] from within pushes URL state", async ({ page }) => {
   await page.click("#add-turbo-action-to-frame")
   await page.click("#link-frame")
+  await nextEventNamed(page, "turbo:frame-load")
+  await noNextEventNamed(page, "turbo:reload")
   await nextEventNamed(page, "turbo:load")
+  await noNextEventNamed(page, "turbo:reload")
 
   const title = await page.textContent("h1")
   const frameTitle = await page.textContent("#frame h2")

Does this reflect the type of scenario you're encountering?

If you're able to cut a branch or open a pull request that reproduced the issue, I'm happy to take it over and explore solutions.

qinmingyuan · 2023-11-30T11:43:55Z

@domchristie I'm unable to reproduce this locally in the following test:

test("navigating turbo-frame[data-turbo-action=advance] from within pushes URL state", async ({ page }) => {                                                                                                        
  await page.click("#add-turbo-action-to-frame")                                                                                                                                                                    
  await page.click("#link-frame")                                                                                                                                                                                   
  await nextEventNamed(page, "turbo:frame-load")                                                                                                                                                                    
  await noNextEventNamed(page, "turbo:reload")                                                                                                                                                                      
  await nextEventNamed(page, "turbo:load")                                                                                                                                                                          
  await noNextEventNamed(page, "turbo:reload")                                                                                                                                                                      
                                                                                                                                                                                                                    
  const title = await page.textContent("h1")                                                                                                                                                                        
  const frameTitle = await page.textContent("#frame h2")                                                  
                                                                                                                                                                                                                    
  assert.equal(title, "Frames")                                                                           
  assert.equal(frameTitle, "Frame: Loaded")                                                                                                                                                                         
  assert.equal(pathname(page.url()), "/src/tests/fixtures/frames/frame.html")                                                                                                                                       
})

I've added some assertions related to turbo:reload:

diff --git a/src/tests/functional/frame_tests.js b/src/tests/functional/frame_tests.js
index b090aff..a796e44 100644
--- a/src/tests/functional/frame_tests.js
+++ b/src/tests/functional/frame_tests.js
@@ -642,7 +642,10 @@ test("navigating a frame with a form[method=get] that does not redirect still up
 test("navigating turbo-frame[data-turbo-action=advance] from within pushes URL state", async ({ page }) => {
   await page.click("#add-turbo-action-to-frame")
   await page.click("#link-frame")
+  await nextEventNamed(page, "turbo:frame-load")
+  await noNextEventNamed(page, "turbo:reload")
   await nextEventNamed(page, "turbo:load")
+  await noNextEventNamed(page, "turbo:reload")
 
   const title = await page.textContent("h1")
   const frameTitle = await page.textContent("#frame h2")

Does this reflect the type of scenario you're encountering?

If you're able to cut a branch or open a pull request that reproduced the issue, I'm happy to take it over and explore solutions.

I can give a Rails Demo App to reproduce this issue. Are you need one ?

afcapel · 2023-11-30T12:05:21Z

@qinmingyuan thanks for the failing test, that's very useful. No need for a rails app, we should fix this within Turbo.

seanpdoyle · 2023-11-30T14:03:06Z

@afcapel I believe the failing test mentioned in the comment is a quote from one of the tests that I attempted to write. Unfortunately, it passes and does not reproduce the issue.

@qinmingyuan if you're able to share a Rails application that reproduces the issue, I'd be happy to troubleshoot further. Thank you!

domchristie · 2023-11-30T22:02:03Z

@seanpdoyle https://github.com/domchristie/turbo_promoted_frame_visit_test

It appears to only impact turbo-rails setups. I tried a minimal demo, serving plain html files (where the frame visit response included a minimal layout to mimic the turbo-rails behaviour), and it worked.

seanpdoyle · 2023-12-01T00:47:23Z

@domchristie I wonder if it's related to a mostly (or completely) empty <head> element coming from turbo-rails:

https://github.com/hotwired/turbo-rails/blob/4eb4e928e30be8cd537af8073f98b80ddea4a578/app/views/layouts/turbo_rails/frame.html.erb#L2-L4

  <head>
    <%= yield :head %>
  </head>

If I copy the application layout, it behaves as expected:

~/Work/domchristie/turbo_promoted_frame_visit_test main*
❯ mkdir -p app/views/layouts/turbo_rails 

~/Work/domchristie/turbo_promoted_frame_visit_test main*
❯ cp app/views/layouts/application.html.erb app/views/layouts/turbo_rails/frame.html.erb

where the frame visit response included a minimal layout to mimic the turbo-rails behaviour

Could you share that code? I wonder what about the Rails setup is different.

qinmingyuan · 2023-12-01T02:16:04Z

@domchristie I wonder if it's related to a mostly (or completely) empty <head> element coming from turbo-rails:

https://github.com/hotwired/turbo-rails/blob/4eb4e928e30be8cd537af8073f98b80ddea4a578/app/views/layouts/turbo_rails/frame.html.erb#L2-L4
  <head>
    <%= yield :head %>
  </head>
If I copy the application layout, it behaves as expected:
~/Work/domchristie/turbo_promoted_frame_visit_test main*
❯ mkdir -p app/views/layouts/turbo_rails 

~/Work/domchristie/turbo_promoted_frame_visit_test main*
❯ cp app/views/layouts/application.html.erb app/views/layouts/turbo_rails/frame.html.erb
where the frame visit response included a minimal layout to mimic the turbo-rails behaviour

Could you share that code? I wonder what about the Rails setup is different.

My code there is nothings in header, but also the same issue:

<html>
  <head></head>
  <body>
    <turbo-frame id="body">
      <%= yield %>
    </turbo-frame>
  </body>
</html>

Re-submission of [hotwired#232][] Related to [hotwired/turbo#1047][] Render full documents, including default layout rendering behavior. Rendering a minimal layout forces `turbo:reload` events because of the severe difference in the contents of the minimal layout's `<head>` and the requesting document's fully populated `<head>`. [hotwired#232]: hotwired#232 [hotwired/turbo#1047]: hotwired/turbo#1047

seanpdoyle · 2023-12-01T02:34:29Z

I've opened hotwired/turbo-rails#534 to re-propose responding to Turbo Frame requests with full documents.

qinmingyuan · 2023-12-01T04:27:51Z

Understood, thanks. Maybe have a better resolution.

domchristie · 2023-12-01T16:00:41Z

Could you share that code? I wonder what about the Rails setup is different.

@seanpdoyle demo gist: https://gist.github.com/domchristie/d143a6e7ae1807bd1f8323ecc8a4978b

seanpdoyle · 2023-12-01T16:40:09Z

@domchristie thank you! Are you saying that despite the fact that the <head> element is empty, that gist works as expected, whereas https://github.com/domchristie/turbo_promoted_frame_visit_test reloads as a mismatch?

domchristie · 2023-12-01T16:42:47Z

@seanpdoyle yes, exactly

seanpdoyle · 2023-12-01T16:53:51Z

@domchristie is there unexpected behavior if you make this change?

-  <script src="https://unpkg.com/@hotwired/turbo@8.0.0-beta.1/dist/turbo.es2017-umd.js"></script>
+  <script src="https://unpkg.com/@hotwired/turbo-rails@8.0.0-beta.1/app/assets/javascripts/turbo.js"></script>

I wonder if the issue stems from the Rails side, or the turbo-rails side.

domchristie · 2023-12-02T08:55:51Z

is there unexpected behavior if you make this change?

@seanpdoyle as that's the ESM version, I changed it to:

  <script type="module">
    import { Turbo } from 'https://unpkg.com/@hotwired/turbo-rails@8.0.0-beta.1/app/assets/javascripts/turbo.js'
    Turbo.start()
  </script>

And it works as expected.

weizheheng · 2023-12-05T15:01:55Z

@domchristie I wonder if it's related to a mostly (or completely) empty <head> element coming from turbo-rails:

https://github.com/hotwired/turbo-rails/blob/4eb4e928e30be8cd537af8073f98b80ddea4a578/app/views/layouts/turbo_rails/frame.html.erb#L2-L4
  <head>
    <%= yield :head %>
  </head>
If I copy the application layout, it behaves as expected:
~/Work/domchristie/turbo_promoted_frame_visit_test main*
❯ mkdir -p app/views/layouts/turbo_rails 

~/Work/domchristie/turbo_promoted_frame_visit_test main*
❯ cp app/views/layouts/application.html.erb app/views/layouts/turbo_rails/frame.html.erb
where the frame visit response included a minimal layout to mimic the turbo-rails behaviour

Could you share that code? I wonder what about the Rails setup is different.

Chipping in here, I am having the same issues where Turbo reloads when promoting Frame Visits using data-turbo-action="…".

Copying the <head></head> from the layout to turbo_rails/frame.html.erb does stops Turbo from unexpected reloading.

domchristie · 2023-12-19T10:43:20Z

It appears to only impact turbo-rails setups. I tried a minimal demo, serving plain html files (where the frame visit response included a minimal layout to mimic the turbo-rails behaviour), and it worked.
#1047 (comment)

This is not correct. The minimal demo did not have data-turbo-track="reload". Adding that, and we see the same behaviour.

domchristie · 2023-12-19T10:46:07Z

@seanpdoyle the minimal repro gist has been updated to demonstrate the issue when data-turbo-track="reload" is present

seanpdoyle · 2024-01-24T18:01:13Z

@afcapel @jorgemanrubia I've encountered this today, and like @domchristie mentioned in #1047 (comment), it's a major impediment to upgrading.

I'm not sure about how to resolve it. Like I mentioned in #1047 (comment), I've opened hotwired/turbo-rails#534. I've also opened #694 to send the Turbo-Action: header when it's present in the requesting context. Turbo Rails could render the full document when both Turbo-Frame: and Turbo-Action: are present. Another alternative is to special-case responses with a completely empty <head>, then intervene to populate them with document.head.innerHTML.

I think #694 (even without the Turbo-Action: header) fits into the Morph-centric mental model: the server renders full HTML documents, then the client decides how to negotiate that new content into the document.

domchristie · 2024-01-25T16:00:52Z

Part of me wonders whether we revise our approach to how we update the history in frame navigations?

We currently start a non-rendering Visit if the frame navigation has an action (added here: https://github.com/hotwired/turbo/pull/398/files#diff-8f44fafd854f6f716d51a2b05b5689266a9b66e0b1ad9d68570bd4e8cefd0a47R269)

This triggers a Visit lifecycle (including checking for tracked assets). To me a Visit is more of a "PageVisit", so I'm wondering if there's another way we could compose this behaviour?

This commit changes the behavior of frame navigations promoted with the `[data-turbo-action]` attribute so that they don't include the `Turbo-Frame` header in their requests. This mimics the existing behavior of frame navigations promoted with `[data-turbo-target=_top]`. If we don't do this turbo-rails will see the `Turbo-Frame` header and render the response as a frame update, with a minimal layout that doesn't include any assets. When Turbo receives the response it believes it's a full page response in which the assets have gone stale and it issues a full page reload with `tracked_element_mismatch` as the reason. Fixes #1047 This is similar to #1138

afcapel · 2024-01-29T11:26:58Z

This is caused because we're sending the Turbo-Frame header in promoted Turbo frame requests, that are intended for full page replacements. Frame navigations that are promoted with [data-turbo-target=_top] already don't include this header. I think navigations promoted with [data-turbo-action] should do the same.

PR in #1143

Fixes #1047 Rendering a frame with a data-turbo-action was rendering the response twice. First, the `FrameController` in charge of the frame renders the response using a FrameRenderer. https://github.com/hotwired/turbo/blob/b7187f13b216cee8c855ef1fb6ac790b40dde361/src/core/frames/frame_controller.js#L314 But when we update a frame with a data-turbo-action, we also issue a visit to update the browser URL & history: https://github.com/hotwired/turbo/blob/b7187f13b216cee8c855ef1fb6ac790b40dde361/src/core/frames/frame_controller.js#L373 This session visit was also triggering a loadResponse callback, which in turn was instantiating a `PageSnapshot` and rendering it. This caused problems when the response for the frame didn't include all the tracked assets in the page. The page snapshot considered the assets stale and triggered a reload of the page with reason `tracked_element_mismatch`. This commit fixes the issue by not rendering the page snapshot when navigating within a frame. The commit includes a new test that reproduces the issue returning a turbo frame in an HTML document with an empty `<head>`. Before this fix, the response would trigger a full page reload.

* Do not render page snapshot when navigating within a frame Fixes #1047 Rendering a frame with a data-turbo-action was rendering the response twice. First, the `FrameController` in charge of the frame renders the response using a FrameRenderer. https://github.com/hotwired/turbo/blob/b7187f13b216cee8c855ef1fb6ac790b40dde361/src/core/frames/frame_controller.js#L314 But when we update a frame with a data-turbo-action, we also issue a visit to update the browser URL & history: https://github.com/hotwired/turbo/blob/b7187f13b216cee8c855ef1fb6ac790b40dde361/src/core/frames/frame_controller.js#L373 This session visit was also triggering a loadResponse callback, which in turn was instantiating a `PageSnapshot` and rendering it. This caused problems when the response for the frame didn't include all the tracked assets in the page. The page snapshot considered the assets stale and triggered a reload of the page with reason `tracked_element_mismatch`. This commit fixes the issue by not rendering the page snapshot when navigating within a frame. The commit includes a new test that reproduces the issue returning a turbo frame in an HTML document with an empty `<head>`. Before this fix, the response would trigger a full page reload. * Do not invalidate if the visit is not rendering Skipping the rendering when the visit comes from a frame navigation breaks a few tests related to caching. Instead, let's make sure we don't invalidate the view if the visit is not rendering. * Add clarifying comment

Re-submission of [hotwired#232][] Related to [hotwired/turbo#1047][] Render full documents, including default layout rendering behavior. Rendering a minimal layout forces `turbo:reload` events because of the severe difference in the contents of the minimal layout's `<head>` and the requesting document's fully populated `<head>`. [hotwired#232]: hotwired#232 [hotwired/turbo#1047]: hotwired/turbo#1047

domchristie mentioned this issue Oct 26, 2023

Let developers access the initiator element in visit/fetch events #750

Open

seanpdoyle mentioned this issue Oct 30, 2023

Create Frame Snapshot from Fetch Response HTML #887

Merged

seanpdoyle mentioned this issue Dec 1, 2023

Render full documents for requests with Turbo-Frame: header hotwired/turbo-rails#534

Open

seanpdoyle mentioned this issue Dec 8, 2023

Add InstantClick behavior #1101

Merged

afcapel mentioned this issue Jan 29, 2024

Don't include Turbo-Frame header in promoted frame navigations #1143

Closed

afcapel mentioned this issue Jan 29, 2024

Do not invalidate pages in visits that don't render #1144

Merged

afcapel closed this as completed in #1144 Jan 30, 2024

seanpdoyle mentioned this issue Feb 21, 2024

Turbo Frame Responses missing tracked elements hotwired/turbo-rails#580

Open

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Promoted Frame Visits cause `tracked_element_mismatch` reloads #1047

Promoted Frame Visits cause `tracked_element_mismatch` reloads #1047

domchristie commented Oct 26, 2023

domchristie commented Nov 24, 2023

afcapel commented Nov 24, 2023

qinmingyuan commented Nov 26, 2023 •

edited

Loading

seanpdoyle commented Nov 29, 2023

qinmingyuan commented Nov 30, 2023

afcapel commented Nov 30, 2023

seanpdoyle commented Nov 30, 2023

domchristie commented Nov 30, 2023

seanpdoyle commented Dec 1, 2023 •

edited

Loading

qinmingyuan commented Dec 1, 2023 •

edited

Loading

seanpdoyle commented Dec 1, 2023

qinmingyuan commented Dec 1, 2023

domchristie commented Dec 1, 2023

seanpdoyle commented Dec 1, 2023

domchristie commented Dec 1, 2023

seanpdoyle commented Dec 1, 2023

domchristie commented Dec 2, 2023

weizheheng commented Dec 5, 2023

domchristie commented Dec 19, 2023

domchristie commented Dec 19, 2023

seanpdoyle commented Jan 24, 2024 •

edited

Loading

domchristie commented Jan 25, 2024

afcapel commented Jan 29, 2024 •

edited

Loading

Promoted Frame Visits cause tracked_element_mismatch reloads #1047

Promoted Frame Visits cause tracked_element_mismatch reloads #1047

Comments

domchristie commented Oct 26, 2023

domchristie commented Nov 24, 2023

afcapel commented Nov 24, 2023

qinmingyuan commented Nov 26, 2023 • edited Loading

seanpdoyle commented Nov 29, 2023

qinmingyuan commented Nov 30, 2023

afcapel commented Nov 30, 2023

seanpdoyle commented Nov 30, 2023

domchristie commented Nov 30, 2023

seanpdoyle commented Dec 1, 2023 • edited Loading

qinmingyuan commented Dec 1, 2023 • edited Loading

seanpdoyle commented Dec 1, 2023

qinmingyuan commented Dec 1, 2023

domchristie commented Dec 1, 2023

seanpdoyle commented Dec 1, 2023

domchristie commented Dec 1, 2023

seanpdoyle commented Dec 1, 2023

domchristie commented Dec 2, 2023

weizheheng commented Dec 5, 2023

domchristie commented Dec 19, 2023

domchristie commented Dec 19, 2023

seanpdoyle commented Jan 24, 2024 • edited Loading

domchristie commented Jan 25, 2024

afcapel commented Jan 29, 2024 • edited Loading

Promoted Frame Visits cause `tracked_element_mismatch` reloads #1047

Promoted Frame Visits cause `tracked_element_mismatch` reloads #1047

qinmingyuan commented Nov 26, 2023 •

edited

Loading

seanpdoyle commented Dec 1, 2023 •

edited

Loading

qinmingyuan commented Dec 1, 2023 •

edited

Loading

seanpdoyle commented Jan 24, 2024 •

edited

Loading

afcapel commented Jan 29, 2024 •

edited

Loading