[Let's provoke some annoyance :-P ]
Oh wait, you just said nothing in the LFC depends on the current way
things work. I really believed in you, so I applied your change and now
my super, next-gen OpenLaszlo application [1] doesn't work anymore in
the new swf9 runtime. Somehow some LFC code [2] assumes it will always
get a valid reference to a node when accessing the immediateparent
property. And also my other best-selling application [3] gives me
runtime errors in swf9 [4]. Can you explain? ;-)
[1]
<canvas debug="true" >
<view>
<view width="220" height="80" bgcolor="#eaeaea" clickable="true"
focusable="true" >
<text text="click and then press tab" />
<handler name="onclick" >
this.parent.destroy();
</handler>
</view>
</view>
</canvas>
[2] it's lz.Focus, the nullpointer-exception is raised in
"genMoveSelection(..)"
[3]
<canvas debug="true" >
<handler name="oninit" >
lz.ModeManager.makeModal(this.a);
lz.ModeManager.makeModal(this.b);
</handler>
<view name="a" />
<view name="b" >
<method name="passModeEvent" args="e, v" >
// side-effects of passModeEvent do occur in real
applications, see LPP-7681!
if (e == "onclick") v.parent.destroy();
return true;
</method>
</view>
<view>
<view width="160" height="80" bgcolor="#eaeaea" clickable="true" >
<text text="click here" />
</view>
</view>
</canvas>
[4] error in "LzNode#childOf(..)" through call from
"handleMouseEvent(..)" in lz.ModeManager
In the current system, when a node is being destroyed, it removes
itself from the node tree (makes itself inaccessible to any parent)
and marks itself as `__LZdeleted`. Some methods protect against
trying to access a node that is in the process of being deleted by
checking this internal property. When this check is not made, it is
possible that a memory leak will be created by accessing the destroyed
node.
The proposed change is define that accessing a node that is in the
process of being deleted is an error.[1]
To facilitate detecting this error, we propose that when a node is
destroyed it will also remove itself from the node tree by setting the
`parent` and `immediateparent` attributes of any of its children
(which will be recursively destroyed as part of destroying the node),
to null, before those children are destroyed.[2]
Pro:
. It is already the case that a destroyed node will remove itself from
its parent and immediateparent subnode (and subview, if it is a view)
lists. If the node has an id, that id will be set to null. If the
node has a name, that name will be set to null in both its parent and
immediate parent nodes.
. There are no known cases in the LFC or components where a child node
needs to access it's parent when the parent is in the process of being
deleted.
. There are several bugs in the LFC where a child node will
(uselessly) update it's parent, even though the parent is in the
process of being deleted. These bugs will be fixed as part of
implementing this API change.
Con:
. It is possible that there is LZX code that could fail due to this
change because it assumes that the `parent` and `immediateparent`
attributes will always refer to a node.
Your comments solicited.
---
[1] By defining this behavior as 'an error', we mean that the behavior
is not supported and may cause your program to operate incorrectly.
The compiler and/or runtime will attempt to signal an error when the
erroneous behavior is detectable, but there may be cases where the
error cannot be detected.
[2] With the proposed change, attempting to access a destroyed node
through the `parent` or `immediateparent` attributes will be signaled
as an error, however, a child node could make a copy of either of
those references and erroneously access a destroyed parent in an
undetectable way.
------------------------------
