- From: Olli Pettay <Olli.Pettay@helsinki.fi>
- Date: Thu, 27 Aug 2009 13:13:14 +0300
- To: Sean Hogan <shogun70@westnet.com.au>, DOM public list <www-dom@w3.org>
On 8/27/09 1:09 PM, Olli Pettay wrote: > On 8/27/09 12:57 PM, Sean Hogan wrote: >> Olli Pettay wrote: >>> On 8/27/09 10:28 AM, Sean Hogan wrote: >>>> Doug Schepers wrote: >>>>> Hi, Sean- >>>>> >>>>> Sean Hogan wrote (on 8/26/09 8:34 PM): >>>>>> If this method could be implemented reliably then it should be >>>>>> kept. It >>>>>> probably wouldn't be so I suppose it should be dropped. >>>>>> >>>>>> What would count as proper use cases and requirements for the >>>>>> replacement? >>>>> >>>>> The same as with any feature request... any solid explanation of a >>>>> real-world use that can't already be done via script, and which >>>>> implementers agree they would support, would serve as a use case. The >>>>> requirements would be those things which must be solved, or must be >>>>> avoided, in designing the feature to solve the use case. >>>>> >>>>> >>>>>> Surely these have already been presented? >>>>> >>>>> Could you elaborate? >>>>> >>>> Actually, I've changed my mind on canDispatch() and I would propose we >>>> keep it (but maybe change the name to hasEvent() as suggested by >>>> Garrett >>>> Smith.) >>>> >>> >>> >>> But how would the hasEvent() work with plugins, extensions or >>> greasymonkey scripts? All those can create random events using >>> the normal DOM Events API. >>> >> >> If they want to dispatch trusted events they will have to register with >> the browsers internal events table. >> Otherwise they can always provide their own equivalent of hasEvent(). >> > > What has trusted events to do with hasEvent()? > (AFAIK, trusted events are gecko specific thing.) (And in gecko nothing needs to be registered "with the browsers internal events table" to be able to dispatch trusted events. Privileged script can dispatch trusted events.)
Received on Thursday, 27 August 2009 10:14:03 UTC