Re: Can Dispatch canDispatch()?

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?

And note, this is not just a theoretical case. For example Firefox
XForms extension dispatches many events, which Firefox itself doesn't
dispatch.



-Olli

> 
> Where would - firesEvent - always return true? Please explain the scenario.
> 
>> Nit, 2) could return true for example if documentElement is <form>.
> 
> Theoretically yeah. I don't know a browser that supports that.
> 
> A limitation to - firesEvent - is that it doesn't say under what
> conditions the event will fire.
> 
> Suppose a new event, take "domfocusin" event, for example, makes it in
> D3E TR (for better or worse). Now suppose a program wants to know if
> "domfocusin" is implemented and can fire. The problem is that the
> object in question may have /potential/ to fire the event, but would
> need certain preconditions met before that would happen.
> 
> <input disabled type="text">
> theInput.firesEvent("domfocusin"); // true.
> 
> theInput fires a focus event when it receives focus. But look, its
> disabled! How will it get focus?
> 
> Or how about:-
> 
> <img style="opacity: 0;">
> 
> theImg.firesEvent("click"); // true, or what about MSIE?
> theImg.style.visibility = "hidden";
> theImg.firesEvent("click"); // true.
> 
> The possibility of the event firing causes - firesEvent - to return
> true, but that doesn't tell the program under what conditions this
> will happen. So, evTarget.firesEvent is an inference check.
> 
> The contending - document.implementation.hasFeature - is also an
> inference check. The hasFeature method provides information about the
> "implementation" object, and not the actual object in question. It
> indicates a generalization of what an implementation claims it does
> and that is a weaker, riskier inference.
> 
> The other problem is where you have an experimental feature that is
> shipped, not done:-
> 
> theImg.firesEvent("contextmenu");
> 
> Where - theImg - has potential to dispatch a "contextmenu" event, but
> the implementation hasn't made it yet possible to trap that event in
> the UI, and so it won't ever happen.
> 
> That is a case that where a program should have a graceful degradation
> strategy, so that if disabling the context menu (and replacing it with
> its own hand-rolled context menu) failed, that the user could still
> perform the functionality otherwise (perhaps by using kbd shortcuts,
> buttons, a sticky menu).
> 
> [snip remainder]
> 
> Garrett
>

Received on Saturday, 29 August 2009 14:08:02 UTC