Re: Can Dispatch canDispatch()?

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?

> 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.

Regards,

Garrett

Received on Tuesday, 1 September 2009 05:54:44 UTC