On Tue, 4 Aug 2026 21:51:36 GMT, Florian Kirmaier <[email protected]> wrote:
> ### Description > > The setup is the following: > Window1 > Window2 owner Window1 > FileChooser owner Window2 > > When Window2 is closed, > then Window2 and the FileChooser are closed, > but the nested event loop from the dialog never returns. > Even worse, Window1 is in a broken state: it can't ever get focus again. > > ### The Fix > The fix has two parts. > > ### Close FileChooser when owner is closed (GlassDialogs.m) > AppKit does not call the completionHandler of the dialog when the owner > window is closed, so the nested event loop is never left. > We add a listener to the owner of the FileChooser, ensuring the FileChooser > gets closed when the owner is closed. > showOpenDialog then returns null, as if the user had cancelled. > > ### Refocus when disabled window becomes key/focused (GlassWindow.m) > When a window becomes focused while it is disabled, the focus isn't processed. > Therefore we resend the focus event when it gets re-enabled. > > ### System test > A system test is included which tests both changes at once. > > ### A note on platform differences > On Windows/Linux, closing the owner of a FileChooser currently doesn't close > the FileChooser at all. For that reason, the test only works on macOS. > But this difference is not introduced by the PR. > It probably would be possible to change that behavior and it would be a good > additional improvement, because in all other cases, closing the owner also > closes the child windows. > > From the Stage JavaDoc (class doc, showAndWait doc): > > When a parent window is closed or iconified, then all owned windows will > be affected as well > > A Stage is hidden (closed) by one of the following means: ... this stage > has a non-null owner window, and its owner is closed > > ### Close API > A possible follow-up would be to provide an API to close the FileChooser > programmatically. > This would also make it easier to write tests. > > --------- > - [x] I confirm that I make this contribution in accordance with the [OpenJDK > Interim AI Policy](https://openjdk.org/legal/ai). @FlorianKirmaier This PR is not `rfr` because you haven't checked the box asserting your compliance with the OpenJDK AI policy, so it is not on anyone's review queue. ------------- PR Comment: https://git.openjdk.org/jfx/pull/2242#issuecomment-5526310176
