Prevention of multiple submits blocks use of back navigation

I'm reopening this because it still exists. At least in my test in Drupal 10.2 but I'm assuming it also exists in 10.3 and 11.
You do have to use certain browsers.

In Chrome this is not an issue for me: version 127.0.6533.89 (Official Build) (arm64)
In Firefox this is an issue: version 130.0.1 (64-bit)
Client working in latest version of Edge also reported this problem.
A colleague working in Firefox Developer Edition (latest up-to-date version) also reported this problem.

This was tested using the test scenario as described by kalpaitch in the original post.

We first encountered this issue in a commerce setup, where this is issue was already reported several times, but no solution yet.
🐛 Using the browser's back button disables checkout button on cart form Active
🐛 Next buttons are blocked until page refresh after use browser's back button Active

There are 2 ways to get it working again (not a fix, but might give some insight into what the problem is):
1/
Inspect the page, navigate to the form element and remove the "data-drupal-form-submit-last" attribute.
2/
Make any change in any of the fields in the form.
Both of these make the form work again.

I have traced back the "data-drupal-form-submit-last" and it has something to do with preventing the form from being submit (double clicking the submit)

Drupal 10.2 is now only receiving security support.

@weseze, Can you confirm that this problem exists on Drupal 11. And are the steps to reproduce in the issue summary correct?

I am going to move this to 11.x for now because changes are made on on 11.x (our main development branch) first, and are then back ported as needed according to our policies and will be visible to more people.

In my testing it affects both Firefox and Chromium.

This affects all submit buttons in a form not just the one that was previously clicked.

So for an example I have a cart form. It has multiple submit buttons. The main one is the checkout button. There are also remove buttons on each cart item and an empty cart button. None of these buttons are functional after clicking back in the browser after submitting the form.

This is the issue where this feature was added
🐛 Double click prevention on form submission Fixed

The feature was intended to prevent double clicking a submit button causing two form submits from happening. It was not intended to prevent the same form from being submitted again after loading the submission page and going back in the browser.

This feature as written causes unexpected behavior in forms across core and contrib. There is no mechanism to opt out a form from this protection. The only way for an end user to fix the page is to refresh the page or change a form value (if they can).

I wrote an event listener for form.js that unsets the double submit data if the page is loaded via the cache (user hits back button), allowing the submit button to work as expected.
If core wants to prevent ever resubmitting a form then it should be a configurable option not a blanket form API feature.

As written this prevents the problem from the original issue, clicking submit multiple times, while avoiding breaking forms when the back/forward buttons are used.

Thanks for reporting.

Issue summary needs to be complete, especially steps and proposed solution sections.

Also will most likely need a test showing the problem.

I've tested the patch by @rhovland on the checkout screen (Commerce 2.36) and it works well. Thank you!

I attempted to address the issue summary. Can you please let me know if there needs to be further changes to it.

In regards to a test, where do you suggest it be placed? It seems FunctionalJavascript tests for forms are located at core/tests/Drupal/FunctionalJavascriptTests/Core/Form. Should a new test file be created there? Should it be added to an existing Form test?

When writing the test what am I testing for? Am I writing a test to ensure that the submit button is disabled when clicked twice? And then navigate back and ensure that it is not disabled? I was unable to find an existing test for the double click prevention feature.

Lastly, is there a way to ensure someone with more experience with javascript reviews the merge request for correctness? I'm uncertain if I did it correctly. There's also a failure of a nightwatch test that I don't really understand (I've never used nightwatch before).

Appreciate your feedback, I'm still learning and have only done work with tests in contrib modules.

This code was added when core either didn't have JavaScript testing or didn't have very much of it.

Reading this, I'm wondering whether we should look at removing this altogether - form.js is not included for every form, it's included only when the library is added, and none of the places in core that include it specify that it's for double click prevention. So we have some forms with double click prevention, and some without, pretty much at random. There is no per-form opt-in or opt-out, so if the js is loaded on the page for any reason, it applies to all forms, not just the one that loaded it. Some of this was pointed out in 🐛 Double click prevention on form submission Fixed after commit too (although the history of that issue is hard to track because it was then moved to Drupal 7 for backport).

I think we should probably discuss whether to remove it altogether before trying to add test coverage, but given this can completely break forms if there's an issue, we'd probably need to add tests both for the original double-click prevention and the back button situation if we go ahead.

I ended up using this solution on the specific page experiencing this issue to avoid any possible issues on other forms. Thanks for the assist, @rhovland.

Why did you overwrite all of the changes made to this issue?

So while I was looking at the history for this issue to revert the changes made, I ran into this issue's bug. I viewed a comparison, then hit back and then tried to view the comparison again and the button didn't work until I reloaded the page.

🐛 Action buttons unresponsive when coming back from node preview Active was marked as a duplicate of this.

When testing that issue I also found some weird behaviour (I didn't realise this was core's JS at the time) where after you hit Back in the browser you can eventually submit the form if you spam the save button a few times.