-
Notifications
You must be signed in to change notification settings - Fork 418
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
Progress bar not displayed when submitting a form #61
Comments
I'm having the same issue, it looks like you have to redirect AFTER handling the form-submission:
That doesn't work for me because I want to redirect the users to a different page, and that extra request is not ideal. An option for me would be to disable Turbo on the actual form, but right now that's not possible, although there is an open PR for that #3 Hopefully that one will get merged soon 🤞 @coorasse please let me know if you find a workaround for this issue. Cheers, |
Ok, I found a temporal solution. Using the custom turbo events, you can capture the
|
I posted on the Hotwire forums asking whether it should be default for the progress bar to always show on form submission. Otherwise, repeatedly rejected forms can appear as no-ops... |
Is this still working for the latest version of Turbo? I'm loading Turbo via the hotwire-rails gem (and via the asset pipeline) and I get a |
Closes hotwired#61 Closes hotwired#147 --- Extends the `Adapter` interface to support new `formSubmissionStarted(FormSubmission)` and `formSubmissionFinished(FormSubmission)` delegate methods to hook into a page's form submission lifecycle. Making the Adapter aware of form submissions provides an opportunity to show and hide the progress bar in the same way as driving the page with Visits. Additionally, replace the `HTMLDivElement` implementation of the progress bar with a [progress][] element and an instance of [HTMLProgressElement][]. When updating the progress, set the `HTMLProgressElement.value` attribute, and let the browser-native implementation update its width. Since the element's `value` attribute is accessible via a property, we no longer have to synchronize via `requestAnimationFrame()`. To support the built-in element, there are some proprietary pseudoelements to consider across the browsers, including: * [-moz-progress-bar][] for the Firefox bar * [-webkit-progress-bar][] for the Safari and Chrome bar background * [-webkit-progress-value][] for the Safari and Chrome bar progress * [-ms-fill][] for IE bars [progress]: https://developer.mozilla.org/en-US/docs/Web/HTML/Element/progress [HTMLProgressElement]: https://developer.mozilla.org/en-US/docs/Web/API/HTMLProgressElement [-moz-progress-bar]: https://developer.mozilla.org/en-US/docs/Web/CSS/::-moz-progress-bar [-webkit-progress-bar]: https://developer.mozilla.org/en-US/docs/Web/CSS/::-webkit-progress-bar [-webkit-progress-value]: https://developer.mozilla.org/en-US/docs/Web/CSS/::-webkit-progress-value [-ms-fill]: https://developer.mozilla.org/en-US/docs/Archive/Web/CSS/::-ms-fill
Closes hotwired#61 Closes hotwired#147 --- Extends the `Adapter` interface to support new `formSubmissionStarted(FormSubmission)` and `formSubmissionFinished(FormSubmission)` delegate methods to hook into a page's form submission lifecycle. Making the Adapter aware of form submissions provides an opportunity to show and hide the progress bar in the same way as driving the page with Visits. Additionally, replace the `HTMLDivElement` implementation of the progress bar with a [progress][] element and an instance of [HTMLProgressElement][]. When updating the progress, set the `HTMLProgressElement.value` attribute, and let the browser-native implementation update its width. Since the element's `value` attribute is accessible via a property, we no longer have to synchronize via `requestAnimationFrame()`. To support the built-in element, there are some proprietary pseudoelements to consider across the browsers, including: * [-moz-progress-bar][] for the Firefox bar * [-webkit-progress-bar][] for the Safari and Chrome bar background * [-webkit-progress-value][] for the Safari and Chrome bar progress * [-ms-fill][] for IE bars [progress]: https://developer.mozilla.org/en-US/docs/Web/HTML/Element/progress [HTMLProgressElement]: https://developer.mozilla.org/en-US/docs/Web/API/HTMLProgressElement [-moz-progress-bar]: https://developer.mozilla.org/en-US/docs/Web/CSS/::-moz-progress-bar [-webkit-progress-bar]: https://developer.mozilla.org/en-US/docs/Web/CSS/::-webkit-progress-bar [-webkit-progress-value]: https://developer.mozilla.org/en-US/docs/Web/CSS/::-webkit-progress-value [-ms-fill]: https://developer.mozilla.org/en-US/docs/Archive/Web/CSS/::-ms-fill
Closes hotwired#61 Closes hotwired#147 --- Extends the `Adapter` interface to support new `formSubmissionStarted(FormSubmission)` and `formSubmissionFinished(FormSubmission)` delegate methods to hook into a page's form submission lifecycle. Making the Adapter aware of form submissions provides an opportunity to show and hide the progress bar in the same way as driving the page with Visits. Additionally, replace the `HTMLDivElement` implementation of the progress bar with a [progress][] element and an instance of [HTMLProgressElement][]. When updating the progress, set the `HTMLProgressElement.value` attribute, and let the browser-native implementation update its width. Since the element's `value` attribute is accessible via a property, we no longer have to synchronize via `requestAnimationFrame()`. To support the built-in element, there are some proprietary pseudoelements to consider across the browsers, including: * [-moz-progress-bar][] for the Firefox bar * [-webkit-progress-bar][] for the Safari and Chrome bar background * [-webkit-progress-value][] for the Safari and Chrome bar progress * [-ms-fill][] for IE bars [progress]: https://developer.mozilla.org/en-US/docs/Web/HTML/Element/progress [HTMLProgressElement]: https://developer.mozilla.org/en-US/docs/Web/API/HTMLProgressElement [-moz-progress-bar]: https://developer.mozilla.org/en-US/docs/Web/CSS/::-moz-progress-bar [-webkit-progress-bar]: https://developer.mozilla.org/en-US/docs/Web/CSS/::-webkit-progress-bar [-webkit-progress-value]: https://developer.mozilla.org/en-US/docs/Web/CSS/::-webkit-progress-value [-ms-fill]: https://developer.mozilla.org/en-US/docs/Archive/Web/CSS/::-ms-fill
@wnm try
|
I noticed that the progress bar is not displayed when submitting a form.
While trying to understand the reason, I noticed that
showProgressBarAfterDelay
is called only after the submit is finished.The method is called by
visitRequestStarted
, called bystartRequest
, and by keep going back into the stack, they are called intoformSubmissionSucceededWithResponse
, so when the submit is already terminated.The result is that the progress ber is not displayed.
Is this a bug, or did I miss something?
The text was updated successfully, but these errors were encountered: