Breaking out of frames documentation is confusing

[wasik]

The documentation states that "The simplest way to achieve this is to specify that the login page requires a full-page reload, by including the turbo-visit-control meta tag".

However, simply adding that tag to your layout/application.html file is insufficient, since Turbo ignores your standard layouts and instead renders layouts/turbo_rails/frame.html.erb.

The documentation says you can use the turbo_page_requires_reload helper to accomplish the same thing, but it's actually a bit different since that method provides content for the yield method inside layouts/turbo_rails/frame.html.erb.

It may be worth making the suggestion to use turbo_page_requires_reload a bit stronger since if you're not an expert in turbo frames, you may not realize your standard layout is ignored with a turbo frame request.

[Petercopter]

@wasik Hey! You beat me to it! 😄 I was just going to submit a similar issue.

I have a lot of forms that open in modals. I upgraded to turbo-rails 1.4.0, and they stopped working correctly. There was a super helpful message in the console about adding a meta tag to get the functionality I wanted.

If I add the meta tag to my application layout (or use the helper, didn't know about it until I read this issue), it gets stripped out, along with all other head contents. Luckily I was dealing with a page that was using a content_for(:head) to place a page title, so I realized that doing this worked:

application.html.haml

!!!
%html
  %head
    = yield :head

show.html.haml

- content_for(:head) do
  %meta{name: 'turbo-visit-control', content: 'reload'}/

It seems like maybe Turbo should not strip out the turbo-visit-control meta tag.

EDIT: Nevermind! Just realized putting the tag in the application layout would not be a great idea. Carry on! Nothing to see here!

[wasik]

It seems like the recent changes in turbo (863) changed the expected behavior of "redirect_to" in Rails. There are some good reasons for this, but it still results in unexpected behavior on the rails side.

There are a bunch of stackoverflow questions about this. In many cases, when people do a redirect_to in rails, they expect the browser to follow that redirect. Instead, they're just seeing the "Content missing" message with an error in the console suggesting they use turbo-visit-control. It would be neat if there were some extra option that could be passed in to redirect_to (eg. "actually_do_the_redirect: true") that could automatically include that header on the page to redirect to, or be intercepted by turbo to do the redirect rather than show the error message.

Others have suggested workarounds, such as manually intercepting turbo:frame-missing, but it would be great if this the best practices were better documented so that when a controller does a "redirect_to", it will actually do the redirect.

Recent stackoverflow workarounds:
https://stackoverflow.com/questions/75738570/getting-a-turbo-frame-error-of-content-missing
https://stackoverflow.com/questions/75701014/using-turbo-frames-how-can-i-reload-the-whole-page-if-the-form-submited-succeede/75704489

[davidalejandroaguilar]

Agree, I think we need a way to break out of the frame from the controller. For example, when a form is successful, otherwise, stay inside the frame.

This was most certainly a breaking change for most of us.

[wasik]

It looks like an effort has been underway for the last 9 months or so to help with this: #367 - that seems like it could provide a way to resolve a lot of these problems.

[glaszig]

it used to work in an earlier version (can't remember which one) but then hotwired/turbo#863 broke everything. confusing situation as can be seen in #122, hotwired/turbo#138, hotwired/turbo#210, hotwired/turbo#502. there were people suggesting the use of custom stimulus controller IN EVERY SINGLE FORM. forms that used to work since even turbolinks' inception but i consider the controller an ugly workaround.

very frustrating.