W3C home > Mailing lists > Public > www-dom@w3.org > April to June 2009

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

From: mikewse <mikewse@hotmail.com>
Date: Thu, 30 Apr 2009 01:58:13 -0700 (PDT)
Message-ID: <23312360.post@talk.nabble.com>
To: www-dom@w3.org

timeless wrote: 
> also note that this would mean that a web site could try to knock out 
> other web based mashups that it didn't like. 

An "evil script" will need to locate the targeted "victim" element in order 
to list/remove its event handlers. If it has the element reference there 
are lots of other things it can do today, like removing the element or
popping up a glass pane in front, stealing all events.

Boris Zbarsky wrote:
> > 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?
> Not if you define "event handers" narrowly as you did above; it does 
> mean that some obvious uses people have had for this in the past are no 
> longer possible.

Right, agreed.

> > 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.
> Thank you for the use case.  Did you control all the event listeners 
> involved, or did you have some way of guaranteeing that the transplanted 
> listeners would still function correctly in the new location?

No, this would be an event handler function written by an unrelated party,
so it certainly wouldn't work if the event handler code f ex depended on
the child element structure. You could say that the contract for using this
DOM transformation is to not have that kind of dependencies. Also in the
current contract is not to use DOM2 events for the reasons discussed here,
but it is resulting in friction as they are at the same time being told to
their fav Ajax lib's event connect features for a number of other reasons.

Jonas Sicking wrote:
> Also, would your example work even if the API only enumerated 
> page-added event listeners, and not listeners added by the 
> implementation or user script? 

Sorry Jonas, I'm not 100% sure on the terminology with "implementation 
and user script", but if you with user scripts are referring to external
files included by the current page (<script src=...>) then, yes, event 
handlers added from these scripts would need to be included in the handler
listing as well.
If my answer is not sufficient, could you maybe give me an example of 
the kinds of scripts you were thinking about?

Best regards
Mike Wilson
View this message in context: http://www.nabble.com/Fwd%3A-RE%3A--DOML3Events--ACTION-267-Proposal-for-event-iterator-tp23287796p23312360.html
Sent from the w3.org - www-dom mailing list archive at Nabble.com.
Received on Thursday, 30 April 2009 08:58:49 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 20 October 2015 10:46:14 UTC