I think it might be possible for _internalNode to leak a listener. Consider if oldWidget had no focusNode, so it created an _internalNode in initState. Then here there is a widget.focusNode. We should call _internalNode.removeListener, but it looks like we don't.

Could you write a test that covers this case?

Good catch! I've handled that case.

I can't find a way to test it, since:

• FocusNode mixes in ChangeNotifier but its hasListeners getter is marked as @Protected
• The _handleFocusChanged callback doesn't affect anything anyway when leaked

We have some automatic leak detection that might catch this. You can run it like:

flutter test --dart-define LEAK_TRACKING=true <path/to/test.dart>

So I think if you just write a test that covers this case it's good enough, even if you can't directly verify that a leak didn't happen. Assuming we don't already have a test that covers this, I would do something like:

• Build a DropdownButtonFormField wrapped in a StatefulBuilder with some boolean to decide whether to pass a focusNode. Start off with no focusNode.
• Maybe expect that it uses focusColor when focused or something.
• Call change your boolean and call setState so it rebuilds and now has no focusNode.
• Expect the focusColor thing again.

Running the test with LEAK_TRACKING=true revealed that a FocusNode is still leaking due to not being properly disposed. I found that we should therefore fully dispose _internalNode rather than just removing the listener.

Interestingly, running the test with or without disposing _internalNode doesn't trigger a leak warning. The warning only appears when we remove the listener without disposing the focus node.

Given that we're now disposing the internal focus node, we can write a more relevant test to cover that, by calling the dispose method again and verifying that it throws an error.

We have some automatic leak detection that might catch this. You can run it like:

flutter test --dart-define LEAK_TRACKING=true <path/to/test.dart>

So I think if you just write a test that covers this case it's good enough, even if you can't directly verify that a leak didn't happen. Assuming we don't already have a test that covers this, I would do something like:

• Build a DropdownButtonFormField wrapped in a StatefulBuilder with some boolean to decide whether to pass a focusNode. Start off with no focusNode.
• Maybe expect that it uses focusColor when focused or something.
• Call change your boolean and call setState so it rebuilds and now has no focusNode.
• Expect the focusColor thing again.

Thanks for including the comment here.

I'm confused by this, why do you create a new FocusNode and not use it anywhere? The widget created by buildFormField will not have a reference to this new FocusNode right?

It doesn't create a new FocusNode variable, it replaces the value of the existing focusNode variable which is used by buildFormField. The focusNode declared at the start of the test is a mutable variable.