Turbo frame action "advance" is ignored

[nunesmatheus]

Hey, thanks for this amazing project. It really makes me excited about web development again!

Bug

As I was using it to build my first iOS application, I noticed a bug that causes my application to work like this:

1. Go to a page that supports pagination
2. Click a pagination link to go the next page (page 2)
3. Refresh the page
4. Result: the refreshed page is page 1
5. Expected result: the refreshed page is page 2

I think this happens because I'm using <turbo-frame> with data-turbo-action attribute as "advance" and it is not being respected, so the navigation works fine, but the URL doesn't change and a refresh sends us back to the initial page that rendered the original turbo-frame.
Basically, I'm expecting this to work natively as well, so correct me if I'm wrong on that assumption: https://turbo.hotwired.dev/handbook/frames#promoting-a-frame-navigation-to-a-page-visit.

Steps to reproduce

1. Run an app that has a turbo-frame with navigation promoted to page visit
2. Open the demo app from this repo on Xcode, point to the application from above and run it
3. Navigate to a page that has pagination
4. Go to the next page
5. Pull to refresh the page and see it go back to the previous page instead of refreshing the current page

I created this tiny Rails app that can be used to test it: https://github.com/nunesmatheus/turbo-frame-promote-visit-demo.

I just ran rails new and added a simple page with pagination links inside a turbo frame that promotes navigation to page visits: nunesmatheus/turbo-frame-promote-visit-demo@950dcd9.

[ibrahima]

I believe I'm seeing this as well. We just started using turbo frames and now the navigation in our Hotwire Native app is basically frozen when you hit a path that uses turbo frames.

[leonvogt]

Hey there,
No guarantee, but I think PR #77 could solve this issue

[ibrahima]

In the issue body you primarily focused on the issue that reloading is broken currently. Based on the documentation you linked, it seems like it should also add to the navigation history, but it doesn't right now. #77 solves the reload issue but does not affect the navigation history.

For the maintainers and community, I'm wondering what the expected behavior should be with regards to the navigation stack. Should it pop additional entries onto the stack? My feeling is that it should, if it is to replicate the web behavior when the action is "advance", but I don't know what is desirable. Thank you!

[joemasilotti]

@nunesmatheus, thanks for bringing this up. It took me a while to wrap my head around why this wasn't expected behavior. Hotwire Native doesn't get involved when a Turbo Frame navigation occurs. If you're trying to push a new page onto the stack then you can add target="_top" to the Turbo Frame tag. From your demo app:

diff --git a/app/views/hello/index.html.erb b/app/views/hello/index.html.erb
index 8ff79a2..58e3882 100644
--- a/app/views/hello/index.html.erb
+++ b/app/views/hello/index.html.erb
@@ -1,5 +1,5 @@

-<turbo-frame id="pagination" data-turbo-action="advance">
+<turbo-frame id="pagination" data-turbo-action="advance" target="_top">
   <h1>Page <%= @page %></h1>
   <p>You are currently on page <%= @page %>.</p>

That said, I agree that changing the href of the page, then reloading it, should reload the new URL, not the old one. So #77 is addressing what I'd consider a bug.

[ibrahima]

Hi Joe, thanks for your response! I was wondering, if turbo action = advance adds a history item on web, should it not then also add a navigation stack entry on native? I also feel like not pushing a navigation stack entry has weird interactions with bridge components, because e.g. the native bridge component can stick around past when that screen is visible. It also doesn't update the title after navigation which works correctly on web. I've also been spelunking through the turbo code to figure out how and why a turbo frame is handled differently than a turbo drive request, but at least in my mind, a turbo frame with turbo-action=advance should behave like a regular navigation in most ways.

Thank you!

Oh, to address your suggestion - adding target="_top" changes the behavior in a way that's not what we want so that's not helpful for our use case. In general it seems like that is solving a different problem and just happens to also make the navigation into its own stack entry.

Edit: I tried poking around and promoting the turbo frame navigation to a full visit, but in my attempt it only ends up rendering the turbo frame contents as the whole page, which doesn't work correctly for me. I realized that this might require changes in both this library and in turbo itself to do it all correctly, if it is even feasible.

[ibrahima]

One other thing to mention about the navigation stack situation: on Android, when using turbo frames with action="advance" I experience the same behavior of not updating the navigation stack. However, it does successfully update the page's title, and reloading does open the same page rather than loading the original page before turbo frame navigation.

My opinion is that both of these are bugs, but for a mobile app I could see the benefit in not updating the navigation stack but only the "reload" URL (especially in this example given of pagination). However, I feel like that behavior might need a different action name rather than "advance" IMO. I think that when using turbo frames to navigate to a specific entry in a list, not updating the navigation stack is a problem, and it's a divergence from the web behavior.