Do not delete files if the user clicks 'Move to Trash' in the context menu while Shift is pressed
Review Request #107509 - Created Nov. 29, 2012 and submitted
The problem occurs in Konqueror and Dolphin if the 'Delete' context menu entry is enabled, and Shift is pressed while Dolphin's context menu is opened. The menu shows both "Move To Trash" and "Delete" then, but clicking "Move to Trash" will also result in a "Delete". The reason seems to be that not only the context menu, but also DolphinViewActionHandler::slotTrashActivated(Qt::MouseButtons, Qt::KeyboardModifiers modifiers) tries to be clever, checks if 'Shift' is pressed and deletes the file then. But I do not see why this is necessary. Both Dolphin's and the DolphinPart's context menu take care of the Shift issue themselves in different ways, and I don't see why an invocation of the "Move to Trash" action should ever need to delete the file. But maybe I've overlooked something, so I thought I'd better have some more people have a look at my patch before I accidentally break something else.
Tested trashing and deleting files in Dolphin and Konqueror with the context menu, the menu, Delete/Shift+Delete key presses, with the 'Delete' action enabled/disabled, and everything seems to work OK for me.
I am sure you did not test the scenario when the user RMB clicks an item and then presses the Shift-key before clicking on the "Move To Trash" action. IOW, if the user presses the Shift key before the RMB click, the correct action ("Delete") is shown in the context menu. Otherwise, the "Move To Trash" is shown. That is the scenario this code was supposed to handle. Simply put Shift+"Move To Trash" == Delete. And I venture to guess that the behavior was not change when the "Delete" action is enable by default for the sake of consistency.
Since the issue blocking this review has been resolved, this change should be committed. However, since the fix for the blocking issue only went into the master branch so should this one I guess.