Form not being submitted

[spaquet]

I'm experiencing some issues on a user creation form which I think is linked to Turbo and the Password Manager negatively interfering with one another.

The create user form that I have works with no flaw on Firefox where I do not use any password manager. On the other hand, Safari and Chrome where the default password managers are activated.

What I've been experiencing so far:

1. The submit button does not trigger meaning that nothing happens: no error in the console, no network transmission (confirmed sever side too)
2. Using the IP address of the server of the FQDN does not change anything
3. Experienced on local dev environment as well as on staging and production
4. When adding data: {turbo: false} to the form... the issue disappear and the form works as expected.

Here is the form where the issue is taking place. Nothing fancy and this is the only element on that page.

<%= form_with model: @user, url: sign_up_path do |form| %>
        <%= render partial: "shared/form_errors", locals: { object: form.object } %>
        <div class="mb-6">
          <%= form.label :email, "Your email", class: "block mb-2 text-sm font-medium text-gray-900 dark:text-gray-300" %>
          <%= form.email_field :email, required: true, autocomplete: "email", class: "bg-gray-50 border border-gray-300 text-gray-900 text-sm rounded-lg focus:ring-blue-500 focus:border-blue-500 block w-full p-2.5 dark:bg-gray-700 dark:border-gray-600 dark:placeholder-gray-400 dark:text-white dark:focus:ring-blue-500 dark:focus:border-blue-500", placeholder:"your_email@example.com" %>
        </div>
        <%= form.fields_for :profile do |f| %>
          <div class="mb-6">
            <%= f.label :nickname, "How you want to introduce yourself to the others", class: "block mb-2 text-sm font-medium text-gray-900 dark:text-gray-300" %>
            <%= f.text_field :nickname, required: true, autocomplete: "nickname", class: "bg-gray-50 border border-gray-300 text-gray-900 text-sm rounded-lg focus:ring-blue-500 focus:border-blue-500 block w-full p-2.5 dark:bg-gray-700 dark:border-gray-600 dark:placeholder-gray-400 dark:text-white dark:focus:ring-blue-500 dark:focus:border-blue-500", placeholder:"Your full name, nickname,... min 3 characters" %>
          </div>
        <% end %>
        <div class="mb-6">
          <%= form.label :password, "Your password", class: "block mb-2 text-sm font-medium text-gray-900 dark:text-gray-300" %>
          <%= form.password_field :password, required: true, autocomplete: "new-password", placeholder: "min 6 characters", class: "bg-gray-50 border border-gray-300 text-gray-900 text-sm rounded-lg focus:ring-blue-500 focus:border-blue-500 block w-full p-2.5 dark:bg-gray-700 dark:border-gray-600 dark:placeholder-gray-400 dark:text-white dark:focus:ring-blue-500 dark:focus:border-blue-500" %>
        </div>
      </div>
      <%= form.submit "Create my account", class: "text-white bg-blue-700 hover:bg-blue-800 focus:ring-4 focus:outline-none focus:ring-blue-300 font-medium rounded-lg text-sm w-full  px-5 py-2.5 text-center dark:bg-blue-600 dark:hover:bg-blue-700 dark:focus:ring-blue-800" %>
 <% end %>

[spaquet]

Environment: Rails 7.0.3.1 Ruby: 3.1 Turbo-Rails 1.1.1 and @hotwired/turbo-rails: 7.1.3

[spaquet]

I also found out that after a force reload the form is behaving as expected. So I went checking the application.js file but I only have the following in it:

import "@hotwired/turbo-rails";
import "./controllers";

[marcelolx]

@spaquet Have you tried in Incognito mode on those browsers?

Also if you go down to @hotwired/turbo-rails: 7.1.2 do you face the same problem?

A sample application would be helpful, so we can try to reproduce it in our environments.

[spaquet]

@marcelolx so, I have tried incognito and that does not seem to change anything. As I mentioned on my previous post the issue seem to resolve when I force a page reload. Let me try with 7.1.2 should not take too long to test today.

[spaquet]

@marcelolx :

1. The issue remains in incognito
2. Moving back to 7.1.2 does not solve the issue too. (changed package.json to 7.1.2, deleted node_modules and yarn.lock before running a yarn install)
3. Adding data: {turbo: false} to the form solved the issue and does not require a page reload to be able to use the form.

[marcelolx]

@spaquet got it, could you provide a sample application in which we can simulate this issue? At least I don't see this happening to me, it may be another dependency in your app or something else that is making Turbo not behave in the way we expect (a sample app will help to find out why)

[spaquet]

@marcelolx Yes I will. I think that I also spotted the root cause. it looks like I have a JS refresh that takes place when I'm following a link_to which should not.

[spaquet]

@marcelolx I think I found the reason why. I need to further test and will confirm tomorrow.

[spaquet]

@marcelolx Here is what triggered the issue: some div tags were not closed. After fixing these tags things went back to normal. The form was properly closed though, meaning that the submit button was before the form's <% end %>

What I still do not understand: 1. Why Firefox was never affected by this issue and 2. Why after reloading the page the form was working on Chrome and Safari.

[marcelolx]

@spaquet Happy to know that you were able to fix your issue!

About your questions, did you compare the HTML on Firefox & Chrome, and were they exactly the same? This may depend on how each browser does handle unclosed elements (I don't know if they handle it differently, but if they do, that could be the reason). About after the reload, when the first visit happens, is it driven by Turbo? Like, if you visit the form page directly by providing the URL to the browser, does the form not work too? My gut here is that Browsers somehow can "handle" this unclosed div, but when the visit to your form is driven by Turbo, the body of the document is replaced with the new body (with the unclosed elements) which may make the browser not be able to "handle" the unclosed element and cause the form submission not to happen.

When I mean "browsers somehow can handle" it is more in a sense of where the browser moves the element in the document if the element is not closed, or something like that (not necessarily that the browser is able to "magically" close the unclosed div)

[spaquet]

@marcelolx I think you are right. What is surprising is that the form was properly closed and the submit button was enclosed within the form tags... But now things are back to normal and this was the only form that was not working. I will try to investigate this a bit more in the future to better understand what caused the issue and how to prevent it as identifying the missing tags was not as easy as it sounds.

[marcelolx]

@spaquet Sure it may not have been, I think https://validator.w3.org/#validate_by_input can help in those cases (of course not always we will assume it is a problem with the markup 😅 )