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

Frames: handle GET form submissions #449

Merged
merged 2 commits into from
Nov 19, 2021

Conversation

seanpdoyle
Copy link
Contributor

Closes 446.

When handling a <form method="get" action="..." data-turbo-frame="..."> submission targeting a <turbo-frame> element,
responses that don't redirect do not change the element's [src]
attribute.

Following the changes made in 424, <form> submissions that result
in GET requests are handled the same as other form submissions in that
they fire turbo:submit-start and turbo:submit-end events. What
424 did not account for is navigations initiated by <form method="get"> submissions that do not redirect.

In response to those requests, this commit adds two additional criteria
for updating the <turbo-frame src="..."> attribute:

  • the response's status code is 200 OK, which is idempotent and does
    not indicate a server-side state change (for example, like a 201
    Created
    with a Location: header might)
  • the response's Content-Type: is HTML (not JSON or even Turbo Stream)

Under those circumstances, the frame's [src] is updated.

This commit adds test coverage for this new behavior along with
additional coverage to guard against regressions.

@seanpdoyle
Copy link
Contributor Author

While investigating this issue, I also uncovered some additional Frame-to-Visit quirks. I've opened #448 to address those.

Closes [446][].

When handling a `<form method="get" action="..."
data-turbo-frame="...">` submission targeting a `<turbo-frame>` element,
responses that don't redirect do not change the element's `[src]`
attribute.

Following the changes made in [424][], `<form>` submissions that result
in `GET` requests are handled the same as other form submissions in that
they fire `turbo:submit-start` and `turbo:submit-end` events. What
[424][] did not account for is navigations initiated by `<form
method="get">` submissions that _do not_ redirect.

In response to those requests, this commit adds two additional criteria
for updating the `<turbo-frame src="...">` attribute:

* the response's status code is [200 OK][], which is idempotent and does
  not indicate a server-side state change (for example, like a [201
  Created][] with a `Location:` header might)
* the response's `Content-Type:` is HTML (not JSON or even Turbo Stream)

Under those circumstances, the frame's `[src]` is updated.

This commit adds test coverage for this new behavior along with
additional coverage to guard against regressions.

[446]: hotwired#446
[424]: hotwired#424
[200 OK]: https://developer.mozilla.org/en-US/docs/Web/HTTP/Status/200
[201 Created]: https://developer.mozilla.org/en-US/docs/Web/HTTP/Status/201
While testing the progress bar rendering, navigate the page to the
`/__turbo/delayed_response` to sleep for 1 second to give the progress
bar a chance to render. Similarly, wait on the `turbo:load` event to
ensure that the progress bar is hidden.
@seanpdoyle
Copy link
Contributor Author

@dhh if this is a good enough fix, I think that it'd be good to include in 7.1.0-rc2.

@dhh dhh merged commit 1562a57 into hotwired:main Nov 19, 2021
@seanpdoyle seanpdoyle deleted the form-targets-action-get branch November 19, 2021 14:45
@agrobbin
Copy link
Contributor

Thanks @seanpdoyle @dhh! I just tried rc2 and everything is looking great.

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

Successfully merging this pull request may close these issues.

GET forms targeting turbo farmes do not update the FrameElement#src on 7.1.0-rc.1
3 participants