The JUCE FileChooser has non-standard behaviour.
Opening a native file chooser to save a file will allow you to click outside this window, and will then move the file chooser to the back.
Standard behaviour is to block clicks on other windows and have the file chooser flash if you attempt this.
At the moment, a plugin can pop open a file chooser window, then if you click anywhere on the host, the file chooser window is moved behind the host and remains open.
Can we please get a fix for this?
Please can you provide the following details:
The native FileChooser stays in front on macOS 13.2/REAPER/VST3, so it seems that this is only a problem on certain platforms.
Iāll test some more today, but so far itās happening on windows 10, vst3 in reaper. Other plugins not made with juce do not exhibit this behaviour.
When loading a chooser from a plugin in Reaper / Cubase 12 / Pro Tools 2022.12 on Windows 11, we can observe that the internals of the plugin window are locked as expected but the hostās windows and the plugin window container can be selected and moved around, and so on, so the chooser can fall behind the DAW window quite easily (which even allows a plug-in to be unloaded in the DAWs I tried while it has a chooser open).
A Reaperās own Save As wonāt let the main Reaper window title be moved which is likely what we would expect.
Thanks, Iāve got a fix for the Windows behaviour on the way.
Iām finding on macOS 13.2 & various hosts if a chooser is started with launchAsync we have the same problematic behaviour as discussed on Windows (so I can do unwise things like unload a plugin while a chooser is open). The old modal loops way (browseForFileToOpen, etc) it locks out interaction with the DAW as desired while the chooser is open.
Will the fix be appropriate for macOS too, since weāre encouraged to move away from using modal loops now?
No, the fix is currently Windows-specific.
Please can you provide the exact steps youāre taking, the expected behaviour, the actual behaviour, and the DAWs, platforms, and plugin formats that youāve tested?
For example:
Itās not quite as bad on macOS because I canāt get the chooser to fall behind the DAW window as it stays always on top but it can be moved off to the side easily in āsaveā mode, so itās sort of clear the chooser is hanging around and should be dismissed (on Windows it can get lost behind windows and forgotten about easily and then who knows what happens to it ultimately).
I think the behaviour youāre seeing is to be expected.
Iāve tested Blue Catās PatchWork and Kontakt 7 in Cubase 12 and Reaper 6.73. In both plugins, if I select āLoadā from the preset menu, the native file chooser prevents me from clicking or interacting with the pluginās editor dialog, but Iām still able to interact (scroll, click, etc.) in the main DAW window.
My fix for Windows exhibits the same behaviour as these non-JUCE plugins.
Itās not expected really because using launchAsync now does not lock the DAW but older code using browseForFileToOpen did, which I think is the proper thing to do so that the DAW cannot be used while a chooser is open for a critical file operation. We could play example tennis with this for a while because there are many plugins doing it one way and many the other. So are you absolutely sure you think it is OK that a chooser can be open and the user in the DAW is able to delete the plugin before its chooser is closed, or other examples of strange workflows that could adjust the state of the plugin being subject to Save-As etc? Reaperās Save-As chooser locks the DAW, I donāt see why a plug-inās Save-As should not.
Yes; when the FileChooser instance is destroyed (e.g. when the editor is closed) the native dialog should be automatically hidden. If that doesnāt work, thatās a JUCE bug.
I donāt think thereās necessarily one correct answer here. Intuitively it makes sense that a DAW project shouldnāt be modified while the user is attempting to load a new project, for example. However, it might well make sense for the user to be able to interact with the DAW (e.g. bouncing/freezing a track to file) while a plugin has a āload wave fileā dialog open. That is, interacting with state outside of the plugin may well be desirable, even while the plugin is modally blocked.
The current behaviour has been in place for a while on macOS, and it seems to be acceptable for users on that platform. Therefore, I suspect that similar behaviour will be acceptable on Windows too.
I donāt agree about the change to the blocking behaviour, but accept thereās room for differences of opinion here. So it is what it is I guess.
With the old technique of course the host could crash if a chooser was opened via browseForFileToOpen and the DAW unloaded the plug-in before the chooser was closed (reasons are understood); so far in my tests unloading a plugin when a chooser opened with launchAsync is still open is working as required (i.e. closing the chooser, and unloading the plugin, without a crash).
Just for the record, I never found that behavior to be acceptable; itās just that there was nothing I could do about it. 
I once tried to question this behavior but never got an answer:
I would like to see the window blocking of the host. I donāt see any situation where you are in the middle of saving or loading a file, and youād want to interact with the host. If you really need to, you cancel the operation. If you stop looking at plugins, and go out to the broader world, the standard is to block interactions with the host. Web browsers, media editors, office tools, etc all behave this way. IMO finding a few plug-in that donāt do it isnāt the benchmark to set.
ā¦I believe thatās not always true. It is only true if we assume that an interaction in the DAW outside of the plug-in cannot alter the internal state of the blocked plug-in.
But, for example, only blocking the plug-in during a āsave stateā operation still leaves the possibility for the user to change the automated parameters of the plug-in via DAW interactions only, and that would alter the state of the plug-in while the āsave stateā window is open, making it unclear whether the saved state is the one before or after the automated parameter change
Could you fill in any detail on the change in behaviour your fix provides?
Itās very similar to the behaviour on macOS. Interactions with the plugin editor window will be blocked, but interactions with the main DAW window will succeed. The native FileChooser will stay on top of the DAW in all cases.
OK. Staying on top of the DAW will help avoid windows being lost in the background.
Is it not feasible for it to lock the DAW out anymore? Or just not something that you consider the way to take the library?
Maybe feasible; would need detailed investigation.
Having similar behaviour between Windows and macOS seems like a good idea for the time being. Iād be against adding the full ālocking outā behaviour just on Windows, for example. If thereās sufficient demand we could take a look at adding it as an option on all platforms, but without a compelling use-case that doesnāt feel like a priority atm.
Thanks for reporting, the behaviour has been updated on develop:
