Re: Can Dispatch canDispatch()?

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?

Garrett

Received on Saturday, 29 August 2009 19:45:30 UTC