Notifications: Restore custom DragHelper
When the notification popup closes, the ListView mode is unloaded to save some resources. On Wayland, during drag and drop another window might be raised and focussed causing the notification popup to close.
QtQuick's built-in drag handling does not take kind to having the item it's operating on destroyed behind its back, particularly because it uses a freaking' nested event loop inside of dragStarted!
Restore the original DragHandler which detaches the drag operation entirely from the item that triggered it. It also creates a proper drag pixmap for dragging the file icon and keeps it for the entire duration of the drag.
As a bonus this also lets us export the URL to the Document portal to enable drag and drop of thumbnails to sandboxed apps.
@fusionfuture @ngraham @davidedmundson
To reproduce, on Wayland: take a screenshot with Spectacle, open notification history, drag the screenshot from there, wait for the popup to close (for some reason it closes immediately, I would have expected it close only when the focus shifts to a new window), then drop it or drag it over the panel or something. It should no longer crash in any of that.
I tried to alleviate it for 6.0 somewhat but couldn’t come up with a satisfying solution. This patch is too invasive so we’ll have to live with it until 6.1 imho.
It’s also quite a high profile one in sentry, manifesting itself in various crashes, e.g. QMimeData::hasImage() or data_source_send when the mime data has been deleted mid drag, anything can happen with a nested event loop with items being deleted… for example https://crash-reports.kde.org/organizations/kde/issues/7590
Dropping to Firefox and Chrome seems broken but that seems consistent with other apps, e.g. Dolphin, dunno what’s going on there.