QFileDialog::getSaveFileName() makes a zombie panel

Hi. I'm not sure GUI: Workspace is the right component to file this against; is there a way to look up the correct component from a class name like QFileDialog?

Anyway. My app calls QFileDialog::getSaveFileName() to run a standard save panel, with this code:

QString desktopPath = QStandardPaths::writableLocation(QStandardPaths::DesktopLocation);
QFileInfo fileInfo(QDir(desktopPath), "graph.pdf");
QString path = fileInfo.absoluteFilePath();
QString fileName = QFileDialog::getSaveFileName(this, "Export Graph", path);
if (!fileName.isEmpty())
...

This is done immediately after a call to QMenu::exec() to run a content menu; the user selects an item in the context menu that says "save a graph", and so I run a save panel to find out where to put the generated graph. This all works great; the save panel runs, it dismisses and disappears, my graph file gets generated, and my app appears to be back in the main event loop and functioning normally. The only sign of trouble is console logs emitted by macOS (10.15.3):

2020-03-29 16:49:42.619 QtSLiM[70268:6158410] WARNING: <NSSavePanel: 0x7f9846e22100> found it necessary to prepare implicitly; please prepare panels using NSSavePanel rather than NSApplication or NSWindow.
2020-03-29 16:49:42.624 QtSLiM[70268:6158410] WARNING: <NSSavePanel: 0x7f9846e22100> found it necessary to start implicitly; please start panels using NSSavePanel rather than NSApplication or NSWindow.
2020-03-29 16:49:42.624 QtSLiM[70268:6158410] WARNING: <NSSavePanel: 0x7f9846e22100> running implicitly; please run panels using NSSavePanel rather than NSApplication.

But now, if the very next thing that I do it to switch to a different app, and then hide that different app so that my app comes to front again, BOOM! the file dialog is back! At this point it seems to be a zombie; it doesn't function properly and doesn't dismiss if Cancel is clicked. I have to quit the app, there seems to be no way to recover. These console logs are sometimes (but not always?) emitted when this occurs:

2020-03-29 16:54:00.606 QtSLiM[70363:6162092] WARNING: <NSSavePanel: 0x7fe0ff216d10> -[NSSavePanel(exportedInterface) requestAppEnabledStateForItems:replyBlock:] no longer has a delegate to respond to shouldEnableURL
2020-03-29 16:54:00.606 QtSLiM[70363:6162092] WARNING: <NSSavePanel: 0x7fe0ff216d10> -[NSSavePanel(exportedInterface) requestAppEnabledStateForItems:replyBlock:] no longer has a delegate to respond to shouldEnableURL

This situation is not triggered by my app calling QFileDialog::getSaveFileName() a second time; I have put console logs in to check for this, and this is definitely not happening. Instead, the save panel seems to have just been temporarily hidden, and when my app comes to the front again, the hidden panel gets shown again even though it's not supposed to be running any more.

Interestingly, if I generate an event in my app before switching to the other app, the problem does not manifest. I.e., if I click a button one time, and then switch to the other app and hide it to bring my app front again, no problem. (Just clicking on a menu in the menu bar, without executing a menu command, does not seem to suffice, though.) It seems like the problem has something to do with the event queue. This is why I mentioned that I'm running the panel in response to a QMenu::exec() call; maybe that sequence of running modal event loops confuses the application logic somehow?

I realize this description is a bit strange! But this is 100% reproducible on my machine, and I'm happy to investigate it further if you have questions. I would very much appreciate a workaround, as this happens to bite my standard workflow, and so it keeps happening to me.