Update (2023-08-08): It seems that redispatching events is allowed in current browsers. In fact, according to bug 412567, Firefox allowed this since 2008. This was a change introduced to become compliant with the Acid3 test.
Original answer for reference below.
This is actually a security mechanism, dispatching an event that has been dispatched before isn't allowed. An event always has additional data associated with it, for example whether it comes from a trusted source (user's keyboard rather than JavaScript code). Some attacks (mostly against MSIE because it had mutable event objects) were using this - they caught a trusted event, changed it and dispatched it again elsewhere (changing might not always be required, dispatching it at a different element is enough for some attacks). In the end disallowing redispatching of events turned out to be the best solution. After all, this functionality isn't really required: creating a new event object with identical properties (minus hidden data) isn't exactly hard.
Pretty much all the security issues in this area were related to the file input control. Some time ago Firefox decided to change the file input UI radically and disallow entering the file name directly. I wonder whether this change made redispatching of events a non-issue. I doubt that anybody will be willing to risk opening this can of worms again however.
document.body.addEventListener("click", ev => {console.log("click!")}); const e = new MouseEvent("click"); for(i=0; i<10; i++) document.body.dispatchEvent(e);
. For me it also works with other Events. And also if I don't create them myself, but reuse a native one... While I understand that reusing events can be problematic, I'm wondering if there aren't use cases where it is justified (e.g. if something is firing tons of change-Events, reusing might improve performance) – Clinandrium