Body is replaced twice when following a redirect during Drive visit

[calleluks]

In a Rails app that I'm working on we have a (Capybara) system test that fails intermittently. The test looks something like this:

test "the thing" do
  visit some_path
  click_on 'Some link' # The target of this link responds with a 302 redirect

  # Sleeping here makes the test pass

  # On the second page
  fill_in 'Some field' # This input has the "required" attribute set
  click_on 'Submit button'

  # On the third page
  assert_text 'The thing succeeded!'
end

Sometimes the test fails because it can't find the text "The thing succeeded!". When inspecting the screenshot, the Capybara driver is stuck on the second page. The form field is empty and Chrome is showing it's built in "Please fill out this field." validation error. It looks as if the field was never filled in but the fill_in method never failed with a missing field error.

I first tried adding sleeps in the test to see if there was a timing issue somewhere. I quickly found that adding a sleep before trying to fill in the field made the test pass consistently.

After looking into many other things, I eventually tried changing the target of the link to point directly to the second page instead of the redirect, and the test passed consistently again!

This made me suspect that the redirect somehow affected Turbo's rendering so I tried adding a console.log in replaceBody and found that it was only called once (as expected) when linking directly to the second page but twice when following the redirect.

The test was failing because it filled in the field after the first call to replaceBody but clicked the submit button after the second call, when the filled in field had been replaced with an empty one.

In an attempt to fix this, I then tried adding back the willRender: false parameter to the call to visitProposedToLocation that was removed in 256418f—and the double render was gone! It also made the test that was added in 256418f fail, though, and I'm not sure how to fix it.

I don't quite understand the change in 256418f but it seems to have been introduced to fix a somewhat unrelated issue? @seanpdoyle, do you think there is any chance we could achieve the same result without introducing a second call to replaceBody?

[seanpdoyle]

@calleluks thank you for opening this issue.

I've opened #804 to try and resolve this. Could you test that change out locally to confirm if it resolves the issue?

[calleluks]

Hey @seanpdoyle, thanks so much for looking into this!

The changes in #804 do resolve the issue! 🎉