SettingsPanel.removePage leaves the page's component in the CardLayout

[NicoKiaru]

SettingsPanel#removePage detaches the tree node before it looks the page up, and the lookup walks the tree (SettingsPanel.java#L130):

public void removePage( final String path )
{
    final MutableTreeNode current = getSettingsPageNode( path, false );
    if ( current == null )
        return; // Path not found in the tree.

    model.removeNodeFromParent( current );
    for ( final SettingsPage page : getPages() )   // getPages() collects from root
    {
        if ( page.getTreePath().equals( path ) )
            pages.remove( page.getJPanel() );
    }
    ...
}

getPages() walks down from root, and the node is already detached, so the loop never matches and the panel stays in the CardLayout.

It shows up when replacing a page, which is the natural use of removePage: adding a page at the same path afterwards leaves two components registered under the same card name, and cardLayout.show( pages, path ) then displays the stale one. The modificationListener addPage registered on the removed page is not removed either.

Seen with 10.6.11, still present on master.

Suggested fix

Take the page from the node before detaching it, which also drops the tree walk:

public void removePage( final String path )
{
    final DefaultMutableTreeNode current = getSettingsPageNode( path, false );
    if ( current == null )
        return; // Path not found in the tree.

    final SettingsPage page = ( ( SettingsNodeData ) current.getUserObject() ).page;
    if ( page != null )
    {
        page.modificationListeners().remove( modificationListener );
        pages.remove( page.getJPanel() );
    }
    model.removeNodeFromParent( current );
    pages.revalidate();
    pages.repaint();
}

Would you like a test and a PR for this? Happy to write both.

---

(Disclaimer: AI written)