I don't fully understand why popupMenuAboutToShow isn't sufficient.
An alternative approach I could think would be allowing the signal handler to delay the menu as necessary rather than having to create the drop job differently?

@mart @dfaure

I have some questions.
1, Should DropJob::setApplicationActions() be called only one time?
2, I see this when I drop multiple file types at once to the desktop (e.g. 2 jpg and 1 zip), the DropJob::setApplicationActions() is called 3 times as follow:

Mimetype Job returns. "image/jpeg"
Received a suitable dropEvent at QPoint(1199,237)
Creating menu for: "image/jpeg" QPoint(1199,237)

Mimetype Job returns. "application/zip"
Received a suitable dropEvent at QPoint(1199,237)
Creating menu for: "application/zip" QPoint(1199,237)

Mimetype Job returns. "image/jpeg"
Received a suitable dropEvent at QPoint(1199,237)
Creating menu for: "image/jpeg" QPoint(1199,237)

But finally only the last one's appActions are added to the menu (the others are overwritten). This is a bit weird.
I want to understand your intention to make this patch as good as possible.

In D26484#591782, @dfaure wrote:

Sorry I have no idea about the calling side in plasma. It sounds buggy indeed, if those are all calls on the same DropJob instance.

Yes, you could check it here: https://phabricator.kde.org/source/plasma-framework/browse/master/src/scriptengines/qml/plasmoid/containmentinterface.cpp
So do you mean this should be fixed to call DropJob::setApplicationActions() only one time?

And do you @mart agree with that?

Hi. I just came across dropping random data (in my case an image) into file views not working, i.e. not creating any new files due to no more data in the QMimeData instance referred to in the DropJob.

Looking into the details, it seems this is due to the flaw of KIO::DropJob being async, but the QDropEvent (which got a respective comment) and even more the QMimeData it exposes (which has no comment, but just a helpless QPointer wrapper) is not defined to outlive the QWidget drop event handler call. And both at least X11 and Wayland protocol seems to negotiate things by the drop serving instance only offering a list of MIME types, next to the copy or move action, and only on the reply of the drop consumer actually deliver the data of the selected MIME type. All this happens during what is wrapped by Qt in the QDropEvent.

My naive reaction to this would be to use some QEventLoop inside KIO::drop() for the user interaction to query "Copy or Move" and "Which format?", then extract the very data from the QMimeData, before returning to the Qt drop event handler call from which KIO::drop() would be called.

But the method added here, DropJob::showMenu() and their usage would not be fixed by this. Anyone around still involved with this who could work on this from their use case POV? Or at least give some thoughts on this?

And now reported the challenge of drop objects lifetime vs user input on decisions by https://bugreports.qt.io/browse/QTBUG-125229