Bug - Dialogs disappear when Ardour lose focus

As the title says.
This affects, for instance, trying to drag’n’drop a file into the import dialog. It is impossible since the dialog disappears as soon as Ardour loses focus.

Using Ardou-6.8.0, Ubuntu 20.6 and Plasma (if that matters).

Yes it matters. Ardour does not manage dialog window focus, your window manager does.

It does not happen here (debian/mate), but the same happens unconditionally on macOS. All child windows of an application are hidden as soon as the application loses focus.

This is not true.

I use several Plasma, Qt, GTK or even more obscure EFL applications. I’ve never had this behaviour with any of them (and I just tested, just to be sure). I also just tested with GIMP which, like Ardour, is written with GTK+ and it works just fine. Ardour is the only application I have suffering from this bug.

I can assure you that Ardour does not explicitly hide windows or dialogs depending on main application focus.

Perhaps check with xwininfo -wm. Ardour does set transient-parent information for child and dialog windows. So window managers can keep those windows on top (z-axis stacking is also delegated to window mangers).

This has nothing to do with the toolkit that’s used.

PS. Check Preferences > Appearance > Quirks. That offers various workaround for WMs that do not follow freedesktop.org specs.

Thank you for the hint. In checking the Preferences Dialog, I noticed that the bug happens ONLY for the import dialog!
The Preferences Dialog does not vanish when Ardour loses focus. Nor does the Open File, Save or Rename dialog. Mixers sure don’t either. Are you sure that the import dialog is a “conventional” dialog?

It is a Window type: Utility (check with xwininfo -wm). It is not a modal dialog so that you can keep interacting with Ardour while the window is displayed.

While Session > Open or Save as… dialogs require interaction with the dialog itself, before you can continue.

I cannot check xwininfo -wm, because it disappears when I try to invoke xwininfo.
Well, if import is the only dialog having this behaviour, maybe it should be reassigned to the same class as the others. This inconsistency is surely confusing. Well, your software, do as you wish xD

You should be able to switch focus with Alt + Tab, and then select the window.

All non-modal dialogs are utility windows. e.g. Menu > Window > Audio/MIDI Setup.
Menu > Window > Plugin DSP Load , …meterbridge, Lua scripting window, etc. the majority of windows, even.

Then again the Preference “All floating windows are dialogs” may fix your case. There is also a KDE setting to do this instead. IIRC related to “focus stealing” in their prefs.