Re: Can Dispatch canDispatch()?

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?

Garrett

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