16337 2012-03-12 21:16:44 +0000 initEvent() 2012-04-27 23:59:44 +0000 1 1 1 Unclassified WebAppsWG HISTORICAL - DOM3 Events unspecified PC Windows NT RESOLVED FIXED http://lists.w3.org/Archives/Public/www-dom/2011JanMar/0068.html LC, needsReview P2 normal --- 1 travil travil annevk bzbarsky mike travil www-dom public-webapps-bugzilla oldest_to_newest 65401 0 travil 2012-03-12 21:16:44 +0000 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/ 65402 1 travil 2012-03-12 21:18:31 +0000 Ooops. Missed my header info... PORT of TRACKER ISSUE-186... [see http://lists.w3.org/Archives/Public/www-dom/2011JanMar/0068.html] 65403 2 travil 2012-03-12 21:20:37 +0000 [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 66950 3 travil 2012-04-23 16:31:17 +0000 Agree with allowing initEvent to be invoked after dispatch. I'm looking through the spec to find places that say things to the contrary... 67152 4 travil 2012-04-27 23:59:44 +0000 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.