Digging further into TextInput code, I made some curious findings (at least for me):
StageText is not GCed because StyleableStageText sets event listeners on changing, change, enter, events etc... when the skin is attached (in TextInputBase partAdded). 2) these event listeners should be removed when the skin is detached and partRemoved is called, but *partRemoved is never called*, => this explains why TI and TI window are not gced, they are locked by SST event listeners, which are themselves locked by the SST pool. Stepping through the code, it appears that detachSkin & partRemoved are called only if mx_internal::skinDestructionPolicy is set to "auto" (it's set to "never" by default). I made a small desktop testing app, and tested it with SDK 4.12 and even SDK 4.6 => detachSkin & partRemoved are never called by default. It seems that this is not a new problem: http://stackoverflow.com/questions/8150934/spark-skinnablecomponent-skindestructionpolicy This is rather weird behavior. Is that expected ? Thoughts? Maurice -----Message d'origine----- De : Maurice Amsellem [mailto:maurice.amsel...@systar.com] Envoyé : mardi 22 avril 2014 11:23 À : dev@flex.apache.org Objet : Question about mobile StageText pool Hi team, I have been working on FLEX-34230 (StageText skins prevents garbage collection of component with TextInputs and TextAreas) and it appears that GC is prevented by the internal pool of StageText used in StageText-based skins (precisely in old StyleableStageText and new ScrollableStageText). Apparently, the purpose of this cache pool is to avoid creating a new StageText if one with the same characteristics is already in the pool (and returning that one). Does someone know why this pool has been introduced ? is it to improve performance because StageText allocation is slow ? I mean, maybe if the reason for it is not valid anymore, the easiest way to fix that would be simply to remove the pool, and create a new StageText everytime time one is needed. Maurice
