W3C home > Mailing lists > Public > www-dom@w3.org > July to September 2009

Re: Can Dispatch canDispatch()?

From: Garrett Smith <dhtmlkitchen@gmail.com>
Date: Sat, 29 Aug 2009 10:52:40 -0700
Message-ID: <c9e12660908291052o65a9a5bbqcd1cb48b8493885c@mail.gmail.com>
To: olli@pettay.fi
Cc: Sean Hogan <shogun70@westnet.com.au>, DOM public list <www-dom@w3.org>
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);


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

Received on Saturday, 29 August 2009 17:53:20 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 20 October 2015 10:46:15 UTC