Submitting a form during an ajax request or before ajax is triggered results in data loss

Um not a bug as far as I can tell. And the solution is kinda hacky.

Don't we also disable all the submit buttons during the AJAX request?

I'm changing this issue into a major bug, because it causes loss of data -- specifically, user input data on a form can be lost when the form is submitted, without warning or explanation.

In particular, this issue always causes loss of data if a user simply edits any textfield that uses an ajax callback, and then clicks the Save button. Because the blur event (the trigger for the ajax processing) occurs simultaneously with the submit event, the modified field is always disabled and therefore missing when the form data is submitted to the server. Users are likely to repeat their edit, get the same result, and simply conclude that it is impossible to make edits on the website.

Re: "the solution is kinda hacky". The solution is functionally equivalent to putting the value into extraData: jquery.form.js puts all the extraData values into hidden input elements. If the jquery developers use this mechanism to add data to the submitted form, presumably it is the most reliable mechanism. Plus it is far preferable to telling users "Stop -- don't hit the Save button unless you have first made sure to click some other random location on your screen and then waited 5 to 10 seconds. Otherwise the Save button will NOT save your data."

I have tweaked the original patch and rerolled it against 8.0.x-dev. I'm also including a 7.x version of the patch, since I needed to roll it for my website.

@Nephele thank you! Patch works perfekt.

There must already exist a more standard way of dealing with this?

Thanks @Nephele. Patch #12 works like a charm

It might be ok, but should consider other solutions too. Such as: make the submit to wait for the blur to finish (or have the submit function perform the blur before submitting.) Hopefully, it can also be tested.

Was just bitten by this on a project, definitely a bug IMHO and fairly hard to identify.

Not submitting a form until ajax sounds interesting but I guess that might also be more complicated to implement?

Confirming that @Nephele's patch #12 fixes the issue. I think that his fix is better than waiting for the ajax to complete. Either way we have to do validation again (obviously when submitted) so why wait for it?

Also confirming Nephele's patch #12 fixes the issue.

+++ b/core/misc/ajax.js
@@ -658,12 +659,18 @@
+      // value is included in all submissions. As per above, submissions that use
...
+      // However, that does not handle IFRAME submissions, nor does it handle any

Line exceeding 80 characters, please review.

Re-roll for 8.4

This is working, but IMHO not in the best way.

This could confuse the user, as blocking the submit this way, the user has to click again in the submit button to submit the form.

I think that after the AJAX call finishes, we should trigger the submit or give the validation error in case the field validation did not pass.
At least this happens in 8.4.

This is not the way, but works. Just as a workaround for the people.

My patch does not work either is getting the previous value :(

Maybe we could try to do something like this somehow: https://stackoverflow.com/questions/4901899/action-on-blur-except-when-specific-element-clicked-with-jquery

So if we lose the focus for the submit button, we do not run AJAX call.

It is not a right solution. Most cases need to wait untill ajax complete before submit.
Image uploading i.e.

So, the right solution, in my opinion, it is disabling submit buttons during ajax requests,

It is not a right solution. Most cases need to wait untill ajax complete before submit.
Image uploading i.e.

So, the right solution, in my opinion, it is disabling submit buttons during ajax requests,

There are 2 separate issues:

1) We should disable the submit button during ajax requests

2) If clicking the submit button triggers an unrelated ajax request (as can happen e.g. if the ajax request is triggered by a changing textfield and clicking the submit button is the first thing a user does after typing in that textfield) then allow that have that unrelated ajax happen first before other submit handling.

Hello my friends. This issue has more than 8 years and is a major because the data loss.
I'm sorry to put extra pressure on it specially because I'm not able to help to conclude it but are we getting a solution soon?

Rerolling patch against 9.3.x

Tried to add a test that checks if the right values are submitted.

Is this related to #2830295: Concurrent ajax submits cause user data loss?

This patch is a life saver. I was totally lost debugging in the backend code as to why my input value was getting lost.
After a long search, found this issue and the patch. Hope this is committed to core soon. Will save a lot of headache!!

Thanks a million!!

regards,
Sukanya

#43 is working for me.

It is nice to see progress on an old issue, thanks everyone!

Reviewing the issue comments I see several that are questioning the solution, #2, #15, #18, #27, #32. I see that #21 supports the solution. Based on that it doesn't seem like there is consensus here on the solution. This needs some discussion. And the result placed in the Issue Summary.

I don't see a code review in this issue. That needs to be done as well.

This should also have a fail patch, to prove the fix is working.

I am removing the Ajax tag because this is in the 'ajax component', per the issue tag guidelines.

Reroll for 9.5.x

Fixed CCF for #52.
Please review.

Reroll against 10.1.x

#49 called for issue summary update which believe still needs to happen.

Fixed, CCF in #55. Attached interdiff for same. leaving as NW, as issue summary still needs to update.

I updated the IS and title based on the discussion to date and my assessment of the issue. The summary of my summary is: there isn’t sufficient support for the original proposed solution as a core fix, but there is overall support and arguments in favor of disabling the submit button.

I agree with #34 that there are 2 separate issues here.

I think that submit should be disabled so that the form can’t be submitted while the ajax change call is running and before the server has responded. If you're going all the way to the server for a change event, it's probably important that it finishes and, if that's the case, the submit button should be disabled until the form is ready to be interacted with again. Since the ajax change call response can modify the values in the form, the user should not be able to submit the form with just the values they provided in the field (e.g., entity reference fields that rely on ajax change events).

However, I don’t think that disabling the submit button addresses the reported issue and, IMO, would unnecessarily expand the scope of this ticket.

The problem described here is that the change event isn’t triggered until the text field loses focus, which can cause data loss because a user can submit the form without losing focus on the field, but before ajax ever runs. In other words, the form gets submitted, but ajax was never triggered, so the value isn’t saved.

I think that further discussion should be around determining what type of event should be used to fire the ajax change.

Reroll of patch in #57 for 10.3.x

Patch #61 does not contain all newly added files.

I recreated the patch again against 11.x. It applies cleanly to 10.3.x as well.

Root cause of the issue: pointer devices (mouse, touchscreen) are allowed to interfere with the Ajax handler process while awaiting a response, leading to incomplete form submission and/or triggering another Ajax call with out-of-sync form data due to ongoing Ajax response expectations.

My proposed solution is to use a locking mechanism to cover two scenarios:
- Lock any form element that contains a defined Ajax handler and submit buttons from being interacted with by a pointer device during the current Ajax call processing;
- Lock any form element that contains a defined Ajax handler and submit buttons from being interacted with by a pointer device during focus on the form element with a defined Ajax handler;

My solution uses CSS property handling instead of additional event handling for a pointer device for a pointer device event locking mechanism. The reason: due to attempts to use the `disable` property or any other way of messing with event listener definitions, causing breaks in form implementations. Using the pointer-events CSS property minimizes the risk of breaking something during the lock mechanism.

Current Ajax handler implementations are working well with keyboard devices. Because the user has to navigate through the form elements to the form submit button, the Ajax handler has a chance to be executed and provide feedback to the user by rendering the throbber element while the Ajax request is being initiated.

It is currently not covered by the tests and needs an accessibility review.

The Needs Review Queue Bot tested this issue. It fails the Drupal core commit checks. Therefore, this issue status is now "Needs work".

This does not mean that the patch necessarily needs to be re-rolled or the MR rebased. Read the Issue Summary, the issue tags and the latest discussion here to determine what needs to be done.

Consult the Drupal Contributor Guide to find step-by-step guides for working with issues.

Upload the patch with MR updates

The patch in #70 works for me.... on my laptop... but it won't deploy on pantheon...

Patch 68 works, and did deploy to pantheon.

Be aware of the known locking issue in #68 related to the file upload widget. This widget uses a different event-triggering chain, which results in the form to which the widget belongs becoming locked.