On Fri, 24 Apr 2026 11:56:09 GMT, Alexander Zvegintsev <[email protected]> wrote:
>> There are about 26 modal FileDialog tests marked as failing on macOS due to >> this bug. >> They test the various modality cases for FileDialog. >> >> The missing macOS support for FileDialog.dispose() affects these tests since >> they require dispose() >> to work to dismiss the dialogs after checking the modality support. >> >> In the macOS native code the FileDialog (an NSOpenPanel) is displayed by >> calling a macOS API "runModalWithDirectory". So it is modal. >> That runModalWithDirectory API is deprecated, but the replacement "runModal" >> is the same as far as this issue goes. >> There is no macOS API to directly hide or progammatically "cancel" the >> dialog. In fact the latter is explicitly disallowed. >> >> But I have found that there is a macOS API "stopModal" which will break the >> loop and dismiss the dialog. >> It seems to work well for these tests. There is a corner-case issue that >> stopModal doesn't take a window parameter. >> Therefore care needs to be taken so that we only stop the loop if the >> current modal window is the one for this FileDialog. >> >> 24 of the 26 tests assume application modal behaviour of the dialog and pass >> with that fix. >> >> Also the ones marked as failing on Linux haven't failed at all for me in all >> my test runs, so all of these are de-problem listed. >> >> The 2 that still fail because they require docmodal/modeless are marked as >> !Mac >> Per the spec there's no requirement to support this, even though apparently >> Linux & Mac do. >> >> class doc says : "The FileDialog class displays a dialog window from which >> the user can select a file. >> Since it is a modal dialog, when the application calls its show method to >> display the dialog, it blocks the rest of the application until the user has >> chosen a file." >> >> The change to test !inDispose is fully explained in the JBS issue, but >> briefly it is required to prevent >> the thread running the dialog from hanging if dispose is called by the >> application. >> >> --------- >> - [x] I confirm that I make this contribution in accordance with the >> [OpenJDK Interim AI Policy](https://openjdk.org/legal/ai). > > src/java.desktop/macosx/classes/sun/lwawt/macosx/CFileDialog.java line 149: > >> 147: if ((nativeCFileDialogPtr != 0L) && (nativeWindowID != 0L)) >> { >> 148: nativeDispose(); >> 149: } > > Why do we need the `nativeCFileDialogPtr` and the `nativeWindowID` at the > java level? > It seems that they can be stored and checked in native within the > `nativeDispose()` call. In order to be sure that these are the native pointers that are associated with this Java Dialog Peer instance. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/30715#discussion_r3139498274
