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.