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

On Fri, May 1, 2009 at 6:00 AM, Mike Wilson <mikewse@hotmail.com> wrote:
> 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.

I don't think that greasemonkey handlers should be exposed since I
think that risks resulting in pages trying to fight off greasemonkey
users. We have seen this in the past where pages try to detect
greasemonkey and then block access to users that are running
greasemonkey.

What you are suggesting might be implementable, but see more below.

> 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?

I'm still very unconvinced of the need for enumerability. I can sort
of see the use case you are describing, but I do think the cost in
implementation complexity is fairly high since the UA will need to
keep track of several different types of event listeners. Further, the
use case you are describing would not be entirely solved by the
ability to enumerate listeners. As Boris points out, there's no
guarentees that the listeners will work when moved to another DOM
node.

Also, adding enumerability doesn't add any new capabilities. It would
strictly be a convenience function. This since the page can always
keep track of any listeners that it adds if it so desires.

/ Jonas

Received on Monday, 4 May 2009 07:49:44 UTC