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?