Memory Management for nsIScriptContext: Difference between revisions

Memory Management for nsIScriptContext (view source)

Revision as of 07:05, 14 September 2005

725 bytes added , 14 September 2005

added an alternative to the first binding option

MarkH

32

edits

@@ Line 55: / Line 55: @@
 ===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.