On Thu, 20 Aug 2026 05:39:58 GMT, Prasanta Sadhukhan <[email protected]> wrote:
>> In Aqua L&F, JOptionPane.showInternalMessageDialog does not close after >> clicking the close icon button but other buttons like "OK" , "Cancel" works. >> It seems `AquaInternalFrameBorder.doButtonAction()` which handles >> `kCloseButton `was not called. >> It is seen that `showInternalMessageDialog()` uses a modal JInternalFrame. >> While that internal frame is modal, AWT filters mouse events so only the >> modal frame’s contents/children can receive them. Aqua paints and handles >> the red close button as part of the JInternalFrame border/title-bar itself >> via >> AquaInternalFrameBorder. drawAllWidgets -> paintButton -> getWidget >> (Widget.TITLE_BAR_CLOSE_BOX) >> https://github.com/openjdk/jdk/blob/5b2d6991a1279d375f9a3c00c7bcd0bbcc7081d6/src/java.desktop/macosx/classes/com/apple/laf/AquaInternalFrameBorder.java#L393 >> >> When close button is presssed, the flow should be >> https://github.com/openjdk/jdk/blob/5b2d6991a1279d375f9a3c00c7bcd0bbcc7081d6/src/java.desktop/macosx/classes/com/apple/laf/AquaInternalFrameUI.java#L528 >> [records the button hit which delegates to the border] >> https://github.com/openjdk/jdk/blob/5b2d6991a1279d375f9a3c00c7bcd0bbcc7081d6/src/java.desktop/macosx/classes/com/apple/laf/AquaInternalFrameUI.java#L536 >> >> https://github.com/openjdk/jdk/blob/5b2d6991a1279d375f9a3c00c7bcd0bbcc7081d6/src/java.desktop/macosx/classes/com/apple/laf/AquaInternalFrameBorder.java#L265 >> >> but it never gets called since >> the click target was the modal JInternalFrame itself, not a child component, >> so the modal filter consumed the event before Aqua code ever saw it, >> >> The fix is to allow events targeted at the modal component itself too >> >> It works for other L&F like Windows because they use Swing JButton for close >> button component in the internal frame title pane. so the click target is a >> child of the modal JInternalFrame, so the filter check is passed. >> There doesn't seem to be a way to fix in macosx classes because Aqua never >> receives the blocked event. The event is consumed earlier in shared AWT >> lightweight-modal dispatch code so the fix is made there >> CI testing is ok and no regression observed. >> >> --------- >> - [x] I confirm that I make this contribution in accordance with the >> [OpenJDK Interim AI Policy](https://openjdk.org/legal/ai). > > Prasanta Sadhukhan has updated the pull request incrementally with three > additional commits since the last revision: > > - Remove close button and close menu from JOptionPane.JInternalFrame > - Remove close button and close menu from JOptionPane.JInternalFrame > - Remove close button and close menu from JOptionPane.JInternalFrame I've manually tested this in multiple L&Fs using all the different showInternal* methods and they all now disable the close button. I didn't find any inconsistency. So assuming all tests pass, this is OK - modulo the small comment update. I will attach my quick hack test program to the JBS issue so others can try it too. The automated test is fine to have but manual verification of this fix is needed. I'd also like you to open an RFE to add those cases (and more actually) in my test program to SwingSet2. Probably on the existing JOptionPane tab. src/java.desktop/share/classes/javax/swing/JOptionPane.java line 1522: > 1520: } > 1521: > 1522: // Option dialogs should be closable only Seems like this comment is no longer accurate. I suggest to replace it with something like // Option dialogs should not be resizable etc., and internal option dialogs are closed via a UI action, not a close button on the dialog title bar. src/java.desktop/share/classes/javax/swing/plaf/basic/BasicInternalFrameTitlePane.java line 191: > 189: private static final String FRAME_TYPE = "JInternalFrame.frameType"; > 190: private static final String OPTION_DIALOG = "optionDialog"; > 191: These can only be used in this class, and you are using the string literals every where else, which mostly defeats the purpose of these constants. I note that we already have 4 occurrences of these .. so I won't ask for it to change, but we ought to look into whether we need a client property registry class (in sun/swing) that can hold such shared constants. ------------- PR Review: https://git.openjdk.org/jdk/pull/32169#pullrequestreview-5309879189 PR Review Comment: https://git.openjdk.org/jdk/pull/32169#discussion_r4098181128 PR Review Comment: https://git.openjdk.org/jdk/pull/32169#discussion_r4098285780
