| Summary: | Widget Explorer can cause drag recipients to crash by destroying itself mid-drag due to auto-close on focus out | ||
|---|---|---|---|
| Product: | [Plasma] plasmashell | Reporter: | Bhushan Shah <bhush94> |
| Component: | Widget Explorer | Assignee: | David Edmundson <kde> |
| Status: | RESOLVED FIXED | ||
| Severity: | crash | CC: | kde |
| Priority: | NOR | ||
| Version: | master | ||
| Target Milestone: | 1.0 | ||
| Platform: | unspecified | ||
| OS: | Linux | ||
| Latest Commit: | Version Fixed In: | ||
| Sentry Crash Report: | |||
|
Description
Bhushan Shah
2014-03-28 13:04:38 UTC
Can reproduce this. Confirming. Reproduced here as well. Not sure about a solution yet - I think what might be happening is that both drop areas (in the panel and the TM) react to the drop and one of them ends up crashing while cloning the QMimeData instance into its internal struct because Qt has already deleted it, assuming the DND operation to be over. Accepting the drop in the TM (it usually doesn't actually care about drops) didn't help. I'm taking a closer look ... The bug is actually in the Widget Explorer: The task activation in the Task Manager causes a focus out on the Widget Explorer dialog, which causes the drag area the drag is spawned from to be destroyed, causing the dragMove and drop handlers in the Task Manager's drop area to crash on deleted data. This is reminiscent of problems I had back when implementing the Task Manager: Windows could be destroyed while a drag from their task delegate is ongoing, and with the drag areas originally children of the task delegates, the same sort of crashes would occur. I eventually solved this by adding a mechanism to the C++ backend to spawn drag instances from there, decoupling it entirely from the task delegates. For the Widget Explorer, the simplest workaround would be never to close the dialog while a drag is ongoing by tracking the state of the drag area and using it to manage the dialog's auto-close behavior property. I'll leave that up to its maintainer to decide. I tried porting to Qt's internal Drag, that still results in the same crash for the exact same reasons. (unsurprisingly really) Delaying the delegate deletion is going to be messy. My best bet is to copy your fix from task manager. EDIT: I don't think using TaskManager.DragHelper will help. The entire dialog is killed when we lose focus, which would kill a top level QtObject too. I do have a lazy fix.
--- a/plasma-desktop/desktoppackage/contents/views/Desktop.qml
+++ b/plasma-desktop/desktoppackage/contents/views/Desktop.qml
@@ -92,7 +92,6 @@ Rectangle {
}
onStateChanged: {
if (sidePanelStack.state == "closed") {
- sidePanelStack.source = ""; //unload all elements
sidePanel.visible = false;
}
}
But that wastes memory. I could maybe put a single shot timer so it only runs once it's finished processing the event loop.
I have a proper fix and prevent the window from closing during a drag. Please kick me if I do not close this when workspace reopens ping. Fixed by 7b7d829ed9c9bb40c6b24f6f346873143e899452 Seems bug hooks aren't working ATM. |