Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

When following a redirect, the resulting HTML is rendered to the page twice #537

Closed
dfritsch opened this issue Feb 14, 2022 · 2 comments · Fixed by #563
Closed

When following a redirect, the resulting HTML is rendered to the page twice #537

dfritsch opened this issue Feb 14, 2022 · 2 comments · Fixed by #563

Comments

@dfritsch
Copy link

I want to first caveat this issue with the fact that it is only causing me problems with flakiness using capybara and selenium based tests. As far as I'm aware, this hasn't caused any actual humans using this any problems.

The problem I'm seeing specifically relates to the following general circumstances:

  • I start on a page with a form that submits via a POST.
  • The endpoint for the POST then redirects to another URL with a form on it
  • Using rspec and capybara to have a fill_in('Label', with: 'value') for this next form, I sometimes see an error where the first input isn't filled in properly.

My understanding of things is that Turbo renders the form once, capybara sees the input on the page and fills it, and then turbo re-renders the form clearing the input entry.

If I'm tracing things properly, I think this is the current set of actions:

  1. Request is made and the browser is told to follow the redirect
  2. The response that actually makes it to the Visit class is the final, redirected response with a 200 status code and HTML to render. This is the first rendering of the page/form.
  3. In the cleanup, there is a check if there was a redirect, and if so it triggers a visit to that new URL using the same response. I believe this is required to update the browser history properly.
  4. That recursion to a new Visit doesn't just update the history though, it will also update the DOM again, which resets anything that is happened (in the milliseconds since the last render).

I'm not sure if there are any use cases where you'd want the second DOM update, but it seems like it would be best to just update the history on the recursion and not do a full update?

@dfritsch
Copy link
Author

Looks like #516 may be the resolution to what I was seeing.

@dhh
Copy link
Member

dhh commented Jun 19, 2022

Solved via #516

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Development

Successfully merging a pull request may close this issue.

2 participants