On Tue, 29 Jul 2025 11:56:49 GMT, Prasanta Sadhukhan <[email protected]> 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
