RFR: JDK-8285893: Hiding dialog and showing new one causes dialog to be frozen [v2]

[Marius Hanl]

On Fri, 23 Feb 2024 17:39:44 GMT, Kevin Rushforth <kcr at openjdk.org> wrote:

> This changes one of the fundamental aspects of entering and exiting a nested event loop. This will need a lot more analysis to show why this is the right approach.

Yes, this is right and I also thought about documenting that as soon as we think that this is the right approach.
I completely agree that we need to analyse this. This is not a simple change but will affect Dialogs and every custom code that uses nested event loops (e.g. I used it for blocking the UI without freezing it for data loading purposes, where we want to wait until the code returns in a non UI blicking way).

Maybe there is a better way as well, I just don't figured out one. 
As described, right now we rely that `enterNestedEventLoop` returns always, which is not happening immediately for ALL platforms, even though Platform has another implementation. Which makes me think the current approach has a flaw, resulting in this behaviour.

> I see the same failure with the most recent patch as I did yesterday. I looked over the changes, and I'm not convinced that this is the right approach.

Thanks for testing. As soon as my colleague is available, I will debug this issue. I don't get why only MacOS is failing, since the low level code is pretty much the same, we just continue right after we left the nested event loop.
I agree that we should find out the root cause why MacOS behaves different.

> I don't know of any supported way to run macOS in a VM on a Windows host, but perhaps others will be able to help.

That was also my understanding the last time I checked. AFAIK, think there is no official way from Apple, but VirtualBox may offer that. Will check as soon as I have more time.

-------------

PR Comment: https://git.openjdk.org/jfx/pull/1324#issuecomment-1962428672