[0:03]* Dantman needs to read all the messages on the nntp mailing lists he's ignored [21:21]<BryanWB> anyone know how i can test that which event listeners are attached to an html element? [21:22]<Dantman> ^_^ That kind of thing is so non cross-browser that jQuery re-implemented it completely when writing .bind... [21:23]<BryanWB> Dantman: i only care about webkit and spidermonkey, are they consistent? [21:24]<Dantman> Oh, I don't know about that far though [21:24]<ashb> BryanWB: lastest safari night web inspector will show it [21:24]<BryanWB> ashb: neat, i wonder how i could script it [21:25]<ashb> not sure [21:25]<BryanWB> ashb: am trying to add unit tests to check that the proper eventhandlers are registered [21:25]<ashb> seems like oyu are testing your JS framework, not your app [21:25]<ashb> do it by mocking the .bind function or similar [21:25]<BryanWB> ashb: yes [21:26]<JoePeck> BryanWB: you won't be able to access the event listener on a node via JavaScript unless you knew about it or its on the "on...." attribute [21:26]<ashb> you dont care that the events are actually bound on the dom, you care that yo ucall .bind [21:26]<JoePeck> BryanWB: you could hijack addEventListener with your own [21:27]<BryanWB> ashb: no, i want to invoke an initialization function on an element, which includes adding event handlers [21:28]<BryanWB> my library adds in helper functions for a lot of html5 elements, audio, canvas, svg, and i want to make sure the correct handlers are there [21:28]<BryanWB> so i do need dom interaction. unless there is a smarter way to test this [21:28]<ashb> you dont care in the unit tests that they are actually added to the elelments do you? you just care that oyu call the function that would add it, no? [21:30]<BryanWB> ashb: well, i care that the addEventListener func was called [21:31]<JoePeck> ashb: if its just a unit test, you can replace it (meaning addEventListener) with your own [21:31]<JoePeck> sorry, BryanWB ^ [21:32]<JoePeck> so Element.prototype._addEventListener = Element.prototype.addEventListener; Element.prototype.addEventListener = function(...) { this._addEventListener.apply(this, arguments); /* Your monitor code here */ [21:33]<JoePeck> there are multiple version of addEventListener you would have to override (Node, Element, window, to name a few). Its not a pretty way to do it [21:34]<BryanWB> JoePeck: hmm, this is getting complicated. tks for suggestion. maybe i will move on to the next test [21:34]<JoePeck> BryanWB: hehe, I agree with your frustration [21:34]<JoePeck> BryanWB: (thats why I added the EventListener support to the Web Inspector) [21:34]<BryanWB> JoePeck: wow tks, maybe i will just test it visually and leave it out of my qunit tests [21:34]<JoePeck> BryanWB: but you need a javascript solution, and there are few catchalls (hijacking or wrapping the addEventListener call) [21:35]<evilstreak> there's a property to list them (eventListenerList) but afaik nothing has implemented it yet [21:35]<BryanWB> evilstreak: then i think i will wait as i need to get to the rest of my library. tks [21:35]<JoePeck> evilstreak: that was taken out of the DOM 3 spec years ago. Maybe some browsers still have them (that would be nice) [21:35]<evilstreak> oh ^_^ [21:35]<BryanWB> JoePeck: darn [21:36]<BryanWB> evilstreak: btw the way i am refactoring my library for smaller functions. tks for the suggestion ;) [21:36]<JoePeck> yah, I researched why you couldn't enumerate listeners and I traced it back to an ARIA complaint that a user could remove their listeners from a node [21:36]<JoePeck> but in actuality, a developer could just clone the node (losing the listeners) and then add their listeners on top [21:37]<JoePeck> so it seems like a useless reason to pull such a useful thing from the spec [23:38]<JohnnyL> if you are using an actor model with a ssj impl. how can you implement it across cores/processors (this probably requires half the code to be rewritten. [23:38]<JohnnyL> ) [23:38]<JohnnyL> ? [23:43]<ashb> whats the actor model? [23:43]<ashb> (i probably know it, but just not by name)