RFR: 4938801: The popup does not go when the component is removed [v6]

[Jeremy Wood]

On Tue, 29 Jul 2025 11:56:49 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

>> Issue is seen that a popup doesn't get closed when the component that invokes it, gets removed from the parent container.
>> This is because the JPopupMenu does not listen to its invoker liefecycle thereby behaving as a standalone entity after creation.
>> Fix is made to make sure popup listens to its invoker lifecycle by registering its PropertyChangeListener to the invoker and listens to the ["ancestor" property name ], https://github.com/openjdk/jdk/blob/441dbde2c3c915ffd916e39a5b4a91df5620d7f3/src/java.desktop/share/classes/javax/swing/JComponent.java#L4853-L4858 which will become null when removed, wherein we should dispose of the popup
>
> Prasanta Sadhukhan has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Use named property listener, update test

Is the PropertyChangeEvent fired *immediately* as the component is added/removed, or is the notification delayed in an invoke-later somewhere? Because if it's delayed: we can check to make sure the information is still relevant.

There are some (probably "bad") UIs that rebuild the UI constantly: they call container.removeAll() and then re-add child components. The end result is usually that the user doesn't perceive a change because the container is stripped and re-built to resemble its original state.

But those UIs may suffer under this PR. (That is: as soon as component is removed the popup is hidden, even if that component is immediately re-added.)

To be clear: I like this PR and have no objection to going forward with it. I think the UI's I'm describing here are badly designed. But it is a potential unintended consequence to consider.

(I can draft a quick example if needed.)

-------------

PR Comment: https://git.openjdk.org/jdk/pull/26407#issuecomment-3133426454