This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.
In most implementations initEvent() can be invoked after dispatch as well. I am not sure why we should disallow that. If we do disallow that, it unsetting the "trusted flag" does not make much sense, as that can never be set in the first place for events an author has control over that are not yet dispatched. It also makes the "requirement" on Event.type twice using different terminology. -- Anne van Kesteren http://annevankesteren.nl/
Ooops. Missed my header info... PORT of TRACKER ISSUE-186... [see http://lists.w3.org/Archives/Public/www-dom/2011JanMar/0068.html]
[see http://lists.w3.org/Archives/Public/www-dom/2011JanMar/0071.html] On 3/4/11 10:21 AM, Anne van Kesteren wrote: > In most implementations initEvent() can be invoked after dispatch as > well. I am not sure why we should disallow that. I believe pages use this to redispatch events.... -Boris
Agree with allowing initEvent to be invoked after dispatch. I'm looking through the spec to find places that say things to the contrary...
With the latest update today, I've resolved this issue so that initEvent can be invoked after dispatch for both trusted and untrusted events. I fixed the few places in the spec that were incongruent with this notion. This should now line up property with DOM4.