Re: Introspection on events

On 11/26/2010 6:01 PM, Olli Pettay wrote:
> On 11/26/2010 05:47 AM, Brett Zamir wrote:
>> Hi,
>>
>> My apologies if this is or has been well covered, but I'd like to know
>> whether there has been consideration for allowing introspection of
>> events already attached to elements or objects?
>
> I guess you mean "event listeners already added to elements".
>
Yes.
>>
>> I'd like to be able to get the event types, attached function(s),
>> whether capturing or not, etc., and possibly also access which events
>> could come through the element via bubbling, or precede it by capturing.
>>
>> I think this could be useful in IDEs, during debugging (and in tools
>> such as Firebug),
> IDEs and tools like Firebug can use browser specific APIs. No
> need to expose everything to web content.
Personally I'm a fan of everything being exposed to web content 
(excepting security, though even that I feel is overly guarded). I don't 
see why pretty much any user-facing app can't be built on HTML5. 
Thankfully that's the direction I see most things going, and I hope it 
won't stop, including as its uses encroach more into browser extension 
territory.
> (Firebug, or at least one its extensions uses
> http://mxr.mozilla.org/mozilla-central/source/content/events/public/nsIEventListenerService.idl 
>
> to look at which listeners are added to an event target)

Maybe I should have rephrased that as Firebug-like tools (including the 
likes of Firebug Lite). Even for simple debugging it would be quite helpful.

>> and also assist when one wishes to dynamically remove
>> all events on an element. No doubt there could be a good number of other
>> interesting use cases.
> Well, if a web page wants to remove all the listeners it has added, it
> sure knows what those listeners are.
Yes. Textboxes could also have required undo functionality to be 
remembered by the application, but certain things are thankfully made 
available for convenience. And if you are dropping in a library which 
allows for manipulation of an application (as I am currently working 
with), you may not be aware of what those listeners are without needing 
to alter the original application.

> There are listeners which web page should not get access to.
> For example the listeners added by UA, or some extension or
> Greasemonkey.
Sure, I can accept that.

>>
>> (This might be especially handy if Mozilla's toSource() could become
>> standardized as well, even if it isn't able to be used to rebuild
>> closures.)
> You mean toSource() in nsIEventListenerInfo? Please file a bug for
> the issue you're seeing.
I am here meaning for it to be made standard (and I know I should bring 
this up elsewhere as on the HTML5 list).

And to add one more item to my wish list, I'd hope to be able to see the 
sequence of event listeners as well, ideally as an array which could be 
get or set.

Brett

Received on Friday, 26 November 2010 11:01:26 UTC