Turbo 7.1 - Turbo stream not handled when using form is using URL dot notation turbo_stream format

I have a form that does some live filtering using turbo streams in a form that does a requestSubmit() as you type. Since upgrading to Turbo 7.1 this approach seems to break and the browser renders the <turbo-stream> as text to the browser, instead of handling the turbo stream.

Downgrading to Turbo 7.0 it works fine.

Even when replacing with a submit button, the result is the same.

My UI:

After typing:

The code I using to request the turbo stream:

        <%= form_tag vacancies_recruitment_applicant_path(@applicant, format: :turbo_stream),
                     method: :get,
                     data: {controller: "form", turbo_frame: "vacancy-search-result"} do |form| %>
          <input type="search" name="query"
                 placeholder="<%= t("common.placeholders.search") %>"
                 autocomplete="off"
                 data-action="debounced:input->form#submit"
                 class="form-control form-control-lg"/>
        <% end %>
      </div>

      <%= turbo_frame_tag "vacancy-search-result" do %>
        <%= render partial: "vacancies", locals: { vacancies: vacancies } %>
      <% end %>

I also noticed that the Turbo Frame header is not inside the request headers in my console, whereas Turbo 7.0 it was sent.

[seanpdoyle]

@acetinick thank you for sharing additional information.

I think I’ve answered my own questions:

However, the screenshot you’ve shared displays /recruitment/applicants/17968/vacancies.turbo_stream?query=a in the browser’s URL bar.

How is that URL being populated?

If it’s from the <form>, then you might have omitted a [data-turbo-action="advance"] declaration from somewhere in your code sample.

If you aren’t using data-turbo-action anywhere in your sample, then it seems that the <form> submissions is being handled outside of the <turbo-frame> you’re mentioning.

Since hotwired/turbo#437, Turbo guards <form> submissions against “external” submissions by calling locationIsVisitable, which calls isHTML. Failing that check results in a page-wide navigation, which explains how the browser’s URL bar is being populated by the navigation in spite of the <form> targeting a <turbo-frame>.

This is a somewhat known issue (related to hotwired/turbo#480 and hotwired/turbo#385).

With that being said, one immediate way to remedy the issue is to encode the request format as a query parameter instead of a URL parameter. For <a> elements and <form method="post"> elements, that would mean encoding [href="/vacancies?format=turbo_stream"] instead of [href="/vacancies.turbo_stream"] (or [action="..."] in the case of <form> elements).

For <form method="get">, encode the parameter as an <input type="hidden" name="format" value="turbo_stream">.

That would handle the quirk of Turbo treating /vacancies.turbo_stream as an external, non-HTML resource.

That should handle it for Rails applications, since the framework treats ?format=... the same as /path.format. If that’s not the case for your server-side framework, you can append the "text/vnd.turbo-stream.html" Content Type to the form submission’s Accept: header:

addEventListener("turbo:before-fetch-request", (event) => {
  if (event.target instanceof HTMLFormElement) {
    const { fetchOptions: { method, headers } } = event.detail

    if (method.match(/get/i)) {
      headers.Accept = [ "text/vnd.turbo-stream.html", headers.Accept ].join(", ")
    }
  }
})

Could you try one of those solutions out and report back with the results?

A (potentially user-facing) fix for this mechanism would also resolve https://github.com/hotwired/turbo/issues/185, and is worth exploring more deeply.

[n-studio]

@tleish My comment was not about data-turbo-stream being set by default.

My comment was about the Accept header being set to text/vnd.turbo-stream.html by default for all form with a get method, or at least the ones with a data-turbo-stream attribute.