Re: Can Dispatch canDispatch()?

On Sat, Sep 5, 2009 at 10:41 AM, Olli Pettay<Olli.Pettay@helsinki.fi> wrote:
>
>
> Garrett Smith wrote:
>>
>> 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?
>
> Why would an event target be "designed" to fire some events.

s/designed to fire/generates.

An EventTarget is generates a "click" event. When it is clicked, the
"onclick" event fires. As other mouse events, "click" is designed for
use with mouse input devices.

> It is something else in the browser which fires an event
> on an event target (well, in some cases it is the event target object itself
> which fires the event).

A script wants to make a more informed decision about which events an
EventTarget will generate.

It is important that the mechanism that a script uses to determine
event support be closely related to the implementation of that
feature. document.implementation.hasFeature is not closely related.

Garrett

Received on Saturday, 5 September 2009 18:25:58 UTC