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:
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.
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?
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:
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:
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?