(e-mail address removed) wrote:
^^^^^^^^^^^^^^^^^^^^
Please put your real name there. In Google Groups, if you absolutely must
use it (see below), by "subscribing" to the newsgroup.
I have two questions:
1.) How best to unit-test an event listener?
2.) Have I properly understood isHostMethod?
I'm trying to unit-test an event listener abstraction but the only way I
can think to test it is against the window 'load' event.
I've a code example here:
https://gist.github.com/1502326
First of all, contrary what Google Groups might suggest to you, this is a
newsgroup, not a Web forum. Primarily it is _not_ on the Web, but in a
separate, plain-text based medium and a network separate from the Internet,
called Network News (a subset of which is Usenet to which the `comp'
hierarchy belongs). So you should post the code that you are asking about,
not just a URL to some Web site (even if it is a code repository).
You should also eschew Google Groups in the first place (except for
research); it is *the* source of newsgroup spam, technically non-compliant
postings, and therefore heavily filtered.
That said, your approach is based on the common misconception that
addEventListener(), attachEvent() and proprietary event-handler properties
would be semantically identical; they are not:
- *Several* event listeners can be added with element.addEventListener() in
order of later execution. In the listener context, `this' refers to
the object that handled the event (the same as `element'). The listener
is passed an event object reference. The event object implements the
standard attributes of the Event interface, like `target' and
`relatedTarget', as properties, and methods like `preventDefault'.
- *Several* event listeners can be added with attachEvent(). Order of
later execution is _not_ guaranteed. `this' refers to the same object
as `window', _not_ to the object that handled the event. The listener
is _not_ passed an event object reference; that has be be acquired from
window.event. The event object does _not_ implement standard attributes,
but has MSHTML-proprietary properties like `srcElement', `fromElement',
`toElement', `returnValue' and `cancelBubble', respectively, instead.
- Only *one* (the primary) event listener can be added with proprietary
event-handler properties. The existing property value will be
*overwritten*. The listener is passed an event object reference unless
the implementation is MSHTML-based (IE). The event object will have
an implementation-dependent set of properties and methods. Depending
on the implementation, the return value of the listener will define
whether the default action for the event is prevented (the event is
canceled) or not.
Bottom line: Eschew attachEvent().
<
http://www.w3.org/TR/DOM-Level-3-Events/#events-EventTarget>
<
https://developer.mozilla.org/en/DOM_Client_Object_Cross-
Reference/DOM_Events> (I am only partially responsible for the current
content and have not reviewed it yet; but it should give you a fair idea
about what is going on).
<
http://www.quirksmode.org/blog/archives/2005/08/addevent_consid.html>
Further, you should _not_ assume that because the object referred to by
`this' (the global object) exposes the method, all objects must expose it,
and that it must be working for all event types. The same applies for the
assumption of the opposite. The more reliable approach, if slightly less
efficient, is to use the approach that appears to be working when the event
was created.
For an event-handling script that implements all of this and has
(therefore?) survived bad storms (no pun intended), see
Also, I'm using David Mark's (@cinsoft) isHostMethod to detect the
relevant host object support but was wondering if I had properly
understood the concepts or not? So for example, am I right in thinking
that a host object/method should be available under the following
conditions (although I understand that these 'conditions' are unreliable):
- if typeof returns 'function' (for majority browsers)
- if typeof returns 'unknown' (for IE < 9 where its implementation used
ActiveX objects for native Functions) - if typeof returns 'object' and the
value isn't 'null' (because ES3 specs have allowed null to return 'object'
which is incorrect behaviour)
That is partially correct. `typeof' is an *operator*, it does not *return*
anything. "unknown" may be the *result* of a `typeof' operation in *all*
DOM implementations; there is no limit as to in which implementations it may
be the result, or up to which MSHTML version it can be returned.
ActiveX/COM has little to do with it; the point is those are *host* objects,
and their `typeof' operation is allowed, by Specification, to result in any
string (loosely speaking). See ECMA-262 Ed. 3 and 5.1, sections 11.4.3, for
details.
[JFTR: I am partially responsible for the way David's isHostMethod() looks
today, for IIRC I have started this is…Method() business with isMethod()
years ago (search the archives). Curiously enough, I have recently
(JSX@234) found it useful to "split" jsx.object.isMethod() so that there
would be jsx.object.isNativeMethod() as well, as David did before, to tell
user-defined event listeners from unsuitable objects apart in event.js.]
If any of these conditions are true then that (again, unreliably) *should*
mean that the specified host method is available to use.
Yes, it should. Unfortunately, it is only so most of the time. A notable
exception is the postMessage() method discussed recently, which apparently
existed before in MSHTML but had a very different implementation (not as
specified in the HTML5 draft).
But even still the host object/method might be implemented differently to
how the specification dictates it should be and so it would be more
accurate to do full 'feature detection' where I create the object and see
if an event is triggered (or some similar test)?
If you mean feature-tests at runtime: No. For you would need to create an
event object as well, which firstly cannot be done everywhere, secondly
would only create an event of one of the numerous event types if it worked,
and thirdly you would require feature detection for that as well. So that
can only reduce your chances of getting a useful event library (0.5³ =
0.125).
HTH
PointedEars
bject.js instead (same SVN