RE: [DOML3Events] ACTION-267 Proposal for event iterator

Jonas Sicking wrote on 28 april 2009 21:57:
> On Tue, Apr 28, 2009 at 12:50 PM, Travis Leithead
> <Travis.Leithead@microsoft.com> wrote:
> > I think this was dropped because it would allow general web 
> > apps to inspect (and remove?) event handlers that were 
> > registered by code running in extensions or by the browser itself.
> 
> That is the initial problem that we in firefox would have with this.

As you pointed out last year, it is a "nice to have" but not crucial
to let the native browser code be able to use the same interfaces as
web page scripts. From an author's point of view I would expect only
other "user code" registered event handlers to be enumerated by the
event iterator, not browser or extension handlers. 

Actually, I think a spec for the event iterator should explicitly say 
that these MUST not be included in the enumeration.

Does that take care of the security issues or am I missing something
else?

The DOM is pretty much up for taking for any script allowed inside, so
are there really any new and dangerous things that can be done just
because event handlers are listable (and therefore removable), that 
cannot be implemented by other means?

> The other problem is a lack of use cases.

In my view the API isn't complete without being able to enumerate a
collection that already has add/remove-methods, and as stated earlier 
I think the main question should be what good reasons there are not to 
include it. Use cases acknowledged by the browser literati or not, I
think this a matter of API completeness.

Personally I have been missing this feature when doing client-side DOM
transformations, f ex transforming more simple element hierarchies 
into widget-like experiences and wanting to move/re-register existing
event handlers into the new element structure. This currently requires 
the initial structure to use DOM0 event attributes.

Best regards
Mike Wilson

Received on Tuesday, 28 April 2009 21:17:37 UTC