Re: Can Dispatch canDispatch()?

On 8/29/09 10:44 PM, Garrett Smith wrote:
> On Sat, Aug 29, 2009 at 11:54 AM, Olli Pettay<Olli.Pettay@helsinki.fi>  wrote:
>>
>>
>> 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.
>>
>
> It would not be possible for - firesEvent - to know that. Is detecting
> native event support possible in Gecko?

If native means not-dispatched by a script, then no, since so far
there hasn't been any need to detect if some event might be dispatched
to a event target. (And in fact there are cases when "valid" events are
dispatched by Firefox UI's javascript.)

I wonder what is your definition for "native event".

-Olli

Received on Monday, 31 August 2009 09:59:07 UTC