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

Jonas Sicking wrote:
> > 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?
> >
> Mike Wilson wrote:
> > 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 script 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?
> 
> With implementation listeners I mean listeners that the UA adds to the
> DOM using normal DOM APIs. For example a UA might use a pair of
> mouseover/mouseout listeners to display the url for a <a> link in the
> statusbar. Or it can use a click listener to temporarily disable the
> popup blocker.
> 
> With user scripts I mean things like grease monkey scripts 
> that adds listeners.

Thanks for the clarification Jonas.

My expectation as a page author would be not to see any trace of 
implementation listeners. My page didn't create these listeners so
it shouldn't list (or at all bother about) them either. My logical
view of this is that the UA uses an internal API that creates a
certain "category" of handlers that are only accessible by the UA.

User scripts are harder for me to have a well-founded opinion about
as I am not aware of their execution model. The little I have used
GreaseMonkey has given me the impression that they behave like 
forcing extra script includes inside your page and from there behave
like any code delivered with the page.
Basically I would like things to work in an analogous way as for
implementation listeners, i e user script event handlers should only
be visible to user scripts and not to page scripts, but I am not
sure on how feasible that is wrt how GreaseMonkey is implemented
today.

So, having said this, what's your view on how these rules (or
variations of them) would affect the possibility of going forward
and specify event handler enumerability in DOM3?

> Note that putting a glass pane in front of a link is unlikely to be a
> useful "defense" for the page. Especially in the case of click
> listeners since that would mean that the link can't be clicked at all
> and so is useless. And similarly, removing the element and replacing
> it with a new one is likely also a useless defense since the UA or
> greasemonkey script can use for example mutation event listeners to
> detect when the new element is inserted and add a listener to that
> element.

I think you may have misunderstood why I mentioned glass pane etc (but
please excuse if I am misunderstanding you now). I was replying to a
post that said enumerability of handlers would be a security problem
in mashups, as portlets could remove or change each other's event 
handlers. I made a few examples on how they may already attack each 
other with existing APIs.

Best regards
Mike

Received on Friday, 1 May 2009 13:01:10 UTC