BUG REPORT: FileChooser

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?

1 Like

Please can you provide the following details:

  • On which platforms do you see this problem?
  • In which plugin formats?
  • In which hosts?

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.

1 Like

Thanks, I’ve got a fix for the Windows behaviour on the way.

1 Like

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:

  • Start Reaper, Pro Tools 2022.12 or Cubase 12.
  • Load plugin (VST2, VST3, AU and AAX tested).
  • Click a button in plugin that opens an async file open or save chooser; chooser opens up.
  • (Optional step) Click in the plugin main window itself, nothing happens as it’s blocked (good).
  • Click basically anything in the DAW itself and it functions (scroll a window, add a track, etc), all interaction seems working (bad, should be blocked by the chooser).

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.

1 Like

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.

1 Like

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).

1 Like

Just for the record, I never found that behavior to be acceptable; it’s just that there was nothing I could do about it. :wink:

I once tried to question this behavior but never got an answer:

1 Like

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.

3 Likes

…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

1 Like

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:

1 Like