Memory Management for nsIScriptContext: Difference between revisions

added an alternative to the first binding option
(added an alternative to the first binding option)
Line 55: Line 55:
===Bound Event Handlers===
===Bound Event Handlers===


The process of binding to an event handler must return an new nsISupports object. (As mentioned above, XUL already stores a different nsISupports pointer from the original event target - it just assumes that pointer has the same lifetime).  A strong reference to this returned object must be kept and the "binding" is only guaranteed to remain alive as long as the object.  Once the binding has been dropped, a new Binding can be created, but it is not guaranteed the returned nsISupports will be the same.
There are 2 options here - one relies on reusing the mechanism above for unbound functions, and the other relies on explicit xpcom strong references.
 
NOTE: I'm still looking at the existing code trying to come up with a concrete proposal.
 
====Have BindCompiledEventHandler() return an out void **====
 
This may be the simplest - this would return a new void **, which must be passed to CallEventHandler().  This new void * is subject to the same rules as unbound handlers, and must be individually unlocked.
 
Language implementations are then free to have this "void *" indirectly hold a strong reference to the event target (or in the case of JS, need only ensure that the wrapper persists)
 
====Formal binding objects====
 
The process of binding to an event handler can return a new nsISupports object. (As mentioned above, XUL already stores a different nsISupports pointer from the original event target - it just assumes that pointer has the same lifetime).  A strong reference to this returned object must be kept and the "binding" is only guaranteed to remain alive as long as the object.  Once the binding has been dropped, a new Binding can be created, but it is not guaranteed the returned nsISupports will be the same.


As this is a strong reference, it will be necessary to ensure these references are manually dropped.  This means that all nsJSEventListener objects must be explicitly dropped.  I believe this already happens now.
As this is a strong reference, it will be necessary to ensure these references are manually dropped.  This means that all nsJSEventListener objects must be explicitly dropped.  I believe this already happens now.
32

edits