Re: Can Dispatch canDispatch()?

On Mon, Aug 31, 2009 at 10:54 PM, Garrett Smith<dhtmlkitchen@gmail.com> wrote:
> On Mon, Aug 31, 2009 at 2:58 AM, Olli Pettay<Olli.Pettay@helsinki.fi> wrote:
>> 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
>
> How about detecting "mouseenter" and "mouseleave", or "onfocusin" or
> the contending analogue "domfocusin" (which seems to be missing a
> corresponding event handler property 'ondomfocusin"). Analog. Makes me
> think of the old Black Sabbath record I used to listen as a kid. Whoa,
> way OT now...
>
> How can a program know if an event will fire?
>

Is it possible for the browser to provide information about which
events an EventTarget is designed to fire?

>> to a event target. (And in fact there are cases when "valid" events are
>> dispatched by Firefox UI's javascript.)
>
> I guess that would mean specified by a standard somewhere.
>
>>
>> I wonder what is your definition for "native event".
>>
>
> I'm trying to describe something that doesn't yet exist.
>
> Native = browser generated, not generated by a program running in the
> browsers. Not "native ES object", not necessarily standard. Does that
> make sense? I don't think there's any proper terminology for it.
>
> I did not use the words "standard" or "specified" because detecting
> proprietary, nonstandard events is desirable, too.
>

Was I unclear?

> Regards,
>
> Garrett
>

Received on Saturday, 5 September 2009 05:29:14 UTC