Re: Enumeration of EventListeners in DOM Level 3 Events

The tension is that if any outside observer can determine the eventListeners
attached to an object they could compromise (either by removing or sending
fake events) any type of constraint, monitoring or replication service.
These would typically be listening to document mutation events instead UI
events.  I raised this issue in
http://lists.w3.org/Archives/Public/www-dom/2001JulSep/0294.html    It would
be like if a SQL transaction was able to suppress a constraint and then put
it back.

The ability for an outside observer to compromise any eventListener seemed
to contradict the motivation behind eventListenerGroup which provided a
mechanism for an eventListener to avoid another eventListener to interfering
with the delivery of events.

These concerns are more on database uses of DOM than UI uses.

There could be a couple of different approaches to satisfy the tension:

a) Have an opt-in list, so that an event listener that wishes to be visible
would respond to a disclosure request.  If the eventListeners disclose
themselves, they could provide an object that describes the event.

b) Have listeners in non-default eventGroups be able to avoid enumeration.
This could be a parameter on the creation of an event group.

c) Have only UI events disclosed.

----- Original Message -----
From: "Richard Schwerdtfeger" <schwer@us.ibm.com>
To: "Ian B. Jacobs" <ij@w3.org>
Cc: "Philippe Le Hegaret" <plh@w3.org>; <w3c-wai-ua@w3.org>;
<w3c-wai-ua-request@w3.org>; <www-dom@w3.org>
Sent: Tuesday, December 11, 2001 7:56 AM
Subject: Re: Enumeration of EventListeners in DOM Level 3 Events


> Ian and Philippe,
>
> Fantastic!
>
> From an authoring tools perspective this is very useful. It allows a
> content developer to programmatically exercise the listeners individually
> so this has advantages to disabled as well as non-disabled users.
>
> From a disabled user perspective, the input device used to simulate the
> activate of each listener may be voice recogntion or some other
specialized
> input device such as an onscreen keyboard combined with:
>
>    big switch
>    specialized keyboard (Don Johnston)
>
> Assistive technologies such as HPR could enumerate the listeners and allow
> the user to select which one to activate. This would aid with users
> creating web sites as well as accessing them. From a UI perspective a
> pop-up window showing the available functions to be executed in response
to
> each event could be activated allowing the user to hear and speak which
one
> to be activated ... and then of  couse activate the appropriate one.
>
> If the WCAG group could do more with Script (require addition of function
> descriptions) it would be nice to have the ability to store the function
> description executed in response to a given event in which case a script
> developer could create a function description for those functions executed
> in response to an event that could be stored and access through the DOM.
> Currently DOM 3 is limited to providing the type definition. ... Perhaps
> for DOM 4 we could add this.
>
> Rich
>
>
> Rich Schwerdtfeger
> Senior Technical Staff Member
> IBM Accessibility Center
> Research Division
> EMail/web: schwer@us.ibm.com
>
> "Two roads diverged in a wood, and I -
> I took the one less traveled by, and that has made all the difference.",
> Frost

Received on Tuesday, 11 December 2001 11:07:42 UTC