This is quite similar as the resolved issue JDK-8097090.

In this case, we have a main stage #1, a modal dialog #2 that has stage #1 as owner, and a modal dialog #3, which also has stage #1 as owner.

On macOS, but not on Windows, when the dialog #3 is closed, (either keeping dialog #2 open or not), there is a beep, which is an indication of a window that is focus disabled trying to become focused.

To reproduce the issue, run the attached test on macOS.

- From the main stage #1, press "Open Dialog #2" to open the modal dialog #2.
- Press "OK" to open dialog #3.
- Either press "OK" to close dialogs #3 and #2, or press "Cancel" to only close dialog #3, and keep #2 still open. Listen to the unexpected beep.

This issue happens when the modal dialog is closed, as WindowStage::setVisible is called for dialog #3, and there is a call to WindowStage::requestToFront to the owner stage #1, even modal dialog #2 is still displayed. The beed is triggered given that the stage #1 is focus disabled at this point.

A possible easy fix can be done by checking if the owner is enabled before doing such call:

@Override public void setVisible(final boolean visible) {
...
   WindowStage ownerStage = (WindowStage)owner;
+ // Check if window is really enabled - to handle nested case
+ if (ownerStage.getPlatformWindow() != null && + ownerStage.getPlatformWindow().isEnabled()) {
       ownerStage.requestToFront();
+ }
...
}

in line with the fix for JDK-8097090.