Re: Can Dispatch canDispatch()?

Garrett Smith wrote:
> On Sat, Aug 29, 2009 at 7:07 AM, Olli Pettay<Olli.Pettay@helsinki.fi> wrote:
>>
>> Garrett Smith wrote:
>>> On Fri, Aug 28, 2009 at 2:54 AM, Olli Pettay<Olli.Pettay@helsinki.fi>
>>> wrote:
>>>> On 8/28/09 10:01 AM, Garrett Smith wrote:
>>>>> On Thu, Aug 27, 2009 at 9:50 PM, Sean Hogan<shogun70@westnet.com.au>
>>>>>  wrote:
>>>>>> Garrett Smith wrote:
>>>>>>> On Thu, Aug 27, 2009 at 12:28 AM, Sean Hogan<shogun70@westnet.com.au>
>>>>>>> wrote:
>>>>>>>
>>>>>>>> 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.)
>>>>>>>>
>>>>>>>>
>>>>>>> That wasn't a name change proposal; it was a straw man. really,
>>>>>>> anElement.hasEvent wouldn't tell a whole lot about the event.
>>>>>>>
>>>>>>> canDispatch is something that reminds me very much of hasFeature. It
>>>>>>> operates on a document level and portends what feature is supported.
>>>>>>> Method hasFeature never was trustworthy, and so I think that
>>>>>>> canDispatch would have the same tendency. It is too far removed from
>>>>>>> the actual problem.
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>> Yes, it is like hasFeature, but there are a few differences which may
>>>>>> mean vendors try to keep it trustworthy:
>>>>>>
>>>>>> - basically hasEvent() is finer grained. It is more like<code>if
>>>>>> (document['addEventListener'])</code>
>>>>>>  than<code>if document.hasFeature("Events", "3.0")</code>.
>>>>>>
>>>>>> - if hasFeature() gives a negative, that doesn't give you any
>>>>>> information about how much of the spec is missing. So devs don't bother
>>>>>> checking it. So vendors don't bother keeping it valid.
>>>>>>  If hasEvent() gives a negative then you just use your fallback. If
>>>>>> it is a false negative then you also lodge a bug report with the
>>>>>> vendor.
>>>>>>
>>>>>> - if hasFeature() gives a false positive, unless it is a major omission
>>>>>> it seems pointless (and petty) to complain to the vendor (about the
>>>>>> false positive).
>>>>>>  If hasEvent() gives a false positive then you could justifiably
>>>>>> lodge a bug report with the vendor and not bother with work-arounds.
>>>>>> This would put the onus on the vendor to report the right value.
>>>>>>
>>>>> Explanation of what the proposed - EventTarget - method - hasEvent -
>>>>> would potentially do, before weighing pros and cons.
>>>>>
>>>>> 1. document.body.hasEvent("click")
>>>>> 2. document.documentElement.hasEvent("submit")
>>>>> 3. document.forms[0].hasEvent("focus")
>>>>>
>>>>> 1. true  -- the body will fire click
>>>>> 2. false -- this element does not fire "submit" events
>>>>> 3. true  -- this element can, if it has a tabIdex, fire focus events
>>>>>
>>>> So hasEvent/firesEvent means "an event called XXX may be dispatched to
>>>> this event target at some point".
>>>> Sounds like that could lead to similar problem what DOMSubtreeModified
>>>> has. A browser may say it supports DOMSubtreeModified, if it even
>>>> theoretically dispatches the event once.
>>>>
>>> That could be a problem, yes. I would not generally rely on mutation
>>> events for production code.
>>>
>>> What you've touched upon is more an issue of the object having
>>> potential to fire the event, but not knowing under what conditions
>>> that will or will not happen. It's a limitation to the method. I
>>> suppose - canFireEvent - is perhaps more apt.
>>>
>>> I've elaborated a little more below.
>>>
>>>> (And because extensions/plugins/greasemonkey may dispatch random events,
>>>> hasEvent/firesEvent could always return true.)
>>>>
>>> I don't understand how greasemonkey could affect the outcome of -
>>> firesEvent -. Can you explain that? I don't understand the problem of
>>> plugins dispatching random events causes issues, either.
>>
>> greasemonkey/extensions/plugins can all run scripts, so they can create
>> new events. So perhaps some greasemonkey script or plugin adds support
>> for a new event type. Let's say "mouseenter". The browser might not
>> support that event, but because the greasemonkey script listens for
>> other mouse events, it can add support for mouseenter and dispatch the
>> event when needed. How could firesEvent() detect such case?
>>
> 
> So greasemonkey can actually modify the event target so that it
> supports "mouseenter", thereby allowing document code to listen to
> that using:-
> 
> evTarg.addEventListener("mouseenter", cb, false);
> 
> ?


Why would the script need to modify "the event target" in any way?
The script can dispatch any events using normal DOM Events methods:
vat evt = document.createEvent(...); evt.initXXXEvent(...); 
someEventTarget.dispatchEvent(evt);

> 
> I could see why someone might want to try that, so that an IE-only
> site might have a chance at getting past a certain part of the code.
> 
> How does it work?
> 
>> And note, this is not just a theoretical case. For example Firefox
>> XForms extension dispatches many events, which Firefox itself doesn't
>> dispatch.
>>
> 
> I see.
> 
> Following that, the question is: If greasemonkey or a third party
> script modifies an event target, is that event detected by -
> firesEvent -?
> 
> It would seem to be related to the underlying mechanism how an event
> is registered and/or dispatched by the extension,and the browser.
I don't quite understand the "event is registered" part.
Events are just dispatched to some event target.

> This
> might vary between implementations. It's possible that implementing a
> - firesEvent - won't fit into Gecko's event model. Would it? Can you
> explain Gecko's events implementation or point to a document that
> explains it?
I'm not quite sure what kind of documentation you'd need.
In the simplest case, event dispatching in Gecko works just like what 
DOM Events defines: createEvent, init the event, dispatch to some event 
target.

-Olli

Received on Saturday, 29 August 2009 18:55:02 UTC