Repository navigation
Fix leaks by disposing in detach - #49999
creativecreatorormaybenot wants to merge 3 commits into
Conversation
|
It looks like this pull request may not have tests. Please make sure to add tests before merging. If you need an exemption to this rule, contact Hixie. Reviewers: Read the Tree Hygiene page and make sure this patch meets those guidelines before LGTMing. |
|
cc @Hixie Can you help me regarding tests? |
|
Cannot fix the leaks for |
|
It turns out that these aren't actually leaks... with the animation controller, the render object starts and stops it on attach/detach already, so there's no resources being consumed while the render object is detached. For the gesture recognizer it's a bit trickier. We can't do the solution that's in this PR because attach/detach happens during GlobalKey reparenting, so for example if someone were to move the Slider around the tree while the finger was down, it would cancel the gesture if we were to dispose/recreate the recognizers. On the other hand, it's true that currently if you put your finger down, then the Slider goes away, then keep moving your finger, the recognizer will keep tracking the finger and may even interfere with the arena if there's other things trying to win the gesture. I'm not 100% sure how to address this, gesture recognizers aren't really compatible with the render object lifecycle... we could move the objects up to the State I guess, and pass them down to the _CupertinoSwitchRenderObjectWidget. The State's dispose is not called during GlobalKey reparenting. The other option would be to add a dispose method to _CupertinoSwitchRenderObjectWidget and have the RenderObjectWidget call it, as a special case for Slider. We should audit the rest of the code to see if other widgets have these problems. |
|
BTW, re tests: leaks in AnimationControllers are already checked for by the test framework, so to see if there's a leak you need but instantiate and initialize the leaking owner (the render object here, attaching it being the key), then dispose of it (detach it, in the case of render objects). For GestureRecognizers there's no particularly good way to test if they've been disposed currently. I would focus on what the symptoms would be... e.g. attach the render object (pump a frame with the widget), start a gesture but don't complete it, detach the render object (pump a new frame with different widgets), and see if the pointer router table is empty, or the gesture arenas are empty, or something like that. |
Description
Fixes #14204.
Tests
I have no idea how to test this - if the existing tests pass, this should be fine I reckon. However, I can add tests if someone can tell me how this would be done.
Checklist
///).flutter analyze --flutter-repo) does not report any problems on my PR.Breaking Change