[Laszlo-dev] LzNode, LzView, LzSprite and destroy

[André Bargull]

Currently, I'm looking at 'LPP-4879 - Memory leak in 
"LzUtils.callback"', and I'm a bit concerned about how "destroy" (for 
LzNode, LzView, LzSprite) should work, how it actually worked in OL3.3.x 
days and what happens right now in OL4.x.

Short summary for OL3.3.x:
LzNode#destroy(..):
    - setting internal flag "__LZdeleted"
    - send "ondestroy" event
    - ... (next steps skipped)
    - recursively invoking destroy on all subnodes
    - removing "name", "id"
    - removing delegates, events, handlers
    - removing itself from immediateparent's subnodes array
    - delete "data"

LzView#destroy(..):
    - ... (first steps skipped)
    - removing itself from immediateparent's subviews array
    - clean up "updatePlayDel" and "doQueuedDel"
    - invoke "super.destroy(..)"
    - return, in case of recursion
    - remove "carefully" MovieClip(s) with "__LZFinishDestroyOnIdle"
    - hide view [setVisible(false)]
    - ... and send "onremovesubview" event

---
Things get a bit more complicated for OL4.x:

LzNode#destroy(..):
    - setting internal flag "__LZdeleted"
    - send "ondestroy" event
    - ... (next steps skipped)
    - recursively invoking destroy on all subnodes
    - removing "name", "id"
    - removing delegates, events
    - removing itself from immediateparent's subnodes array
    - delete "data"
    - ...
Differences:
    - step "removing handlers" has been removed

LzView#destroy(..):
    - ... (first steps skipped)
    - invoke "sprite.predestroy()"
    - removing itself from immediateparent's subviews array
    - invoke "super.destroy(..)"
    - return, in case of recursion
    - invoke "sprite.destroy()"
    - hide view [setVisibility('hidden')]
    - ... and send "onremovesubview" event
Differences:
    - added step: invoke "sprite.predestroy()"
    - removed step: clean up "updatePlayDel" and "doQueuedDel"
    - added step: invoke "sprite.destroy()"
    - removed step: remove "carefully" MovieClip(s) with 
"__LZFinishDestroyOnIdle"
Notes:
    - invokes "sprite.destroy(..)" always with false as the argument(!)
    --> this is a bug, must be true instead of false

LzSprite#destroy (dhtml):
    - checking internal flag "destroyed"
    - recursively invoking destroy on all __children, if argument 
"recursive" is true (will never happen see above)
    - destroy __ImgPool
    - remove js-events and various html-elements
    - ... and setting internal flag "destroyed"

LzSprite#destroy (swf):
    - recursively invoking destroy on all sprites of the subviews of its 
owner, if argument "recursive" is true (will never happen see above)
        --> wait a min', on all subviews of its owner? so that'd be an 
empty subviews array, reason: see [step 3] of LzView#destroy(..)
            --> that's just another bug
    - clean up "updatePlayDel" and "doQueuedDel"
    - remove MovieClip(s) with "__LZFinishDestroyOnIdle"

---

If anybody could follow me up to here: I'm just curious to know, how to 
solve these two bugs.
I'd say, we need to call "this.sprite.destroy(true)" in 
LzView#destroy(..), that's somehow obvious.
But the LzSprite(swf)-subview issue is a bit more complicated:
To match OL3.3.x behaviour, we could simply move 'clean up 
"updatePlayDel" and "doQueuedDel"' to "LzSprite#predestroy(..)" and
remove this "recursively destroy sprites of owner's subviews"-stuff 
completely, so that LzSprite#destroy(..) will only call 
"__LZFinishDestroyOnIdle".
BUT, do we need to remove properly ~all~ MovieClips to avoid 
memory-leaks or whatsoever? However, we didn't do this in OL3.3.x...!?

And a last question:
Why don't we remove all handlers in LzNode#destroy(..) anymore?


- André