I have a form with a formdata event handler that updates a field of the FormData if a certain state is found in the DOM. After the form submission, the DOM needs to be changed, but the formdata event handler should still observe the old state. Currently, I achieve this by using setTimeout(() => {/*...*/}, 0) in a submit event handler on the same form, because this will enqueue the function to run later – hopefully, after the formdata event is handled. My question is: Is this behavior guaranteed, and if not, is there a specification-backed way to accomplish this behavior?
In the specification of event loops, the first step for choosing what work to do next is described as:
Let taskQueue be one of the event loop’s task queues, chosen in an implementation-defined manner […]
The oldest task from this chosen queue is then run later on. This would mean, that if functions scheduled with setTimeout are in the same task queue as the event handlers and if the formdata event handler is scheduled before the submit handler is actually run, I would definitely be safe – I cannot find any evidence for that though. From the documentation of the formdata event (“fires after the entry list representing the form’s data is constructed”) and the fact, that the formdata handler is run after the submit handler, I would even assume the contrary to be true – but that is not what I observed with the approach described above.