Bug 398375 - Dragging a file can trigger inline rename
Summary: Dragging a file can trigger inline rename
Status: RESOLVED FIXED
Alias: None
Product: dolphin
Classification: Applications
Component: general (show other bugs)
Version: 18.04.3
Platform: unspecified Linux
: NOR normal
Target Milestone: ---
Assignee: andreas.krutzler
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2018-09-07 18:33 UTC by 16f87xa
Modified: 2018-10-03 18:08 UTC (History)
4 users (show)

See Also:
Latest Commit:
Version Fixed In: 18.08.2


Attachments
the video show the problem described in the description (3.29 MB, video/x-matroska)
2018-09-07 18:33 UTC, 16f87xa
Details

Note You need to log in before you can comment on or make changes to this bug.
Description 16f87xa 2018-09-07 18:33:10 UTC
Created attachment 114835 [details]
the video show the problem described in the description

There is a problem if I move a file from one folder to another in split view (the problem seems to show only with the view in detail mode).
How you can see in the video if I move the file it may happen that the name of the file I was moving is written in another file of the folder. As a consequence after I have moved the file I get two different files with the same name, one -the original- in the first folder and another different but with the same name of the first, in the second folder.
Comment 1 Wolfgang Bauer 2018-09-18 13:43:24 UTC
I see in your video that the inline rename appears intermediately, maybe that causes the accidental rename?
I.e. does it help if you disable "inline rename" in dolphin's settings?

Btw, I can reproduce the inline rename problem here.
It only seems to happen when the file was already selected, and I move the mouse immediately after pushing down the mouse button without any delay at all.
That's only "cosmetical" here though, and didn't cause any accidental file rename in my testing...
Comment 2 Wolfgang Bauer 2018-09-18 20:25:24 UTC
Btw, this is also mentioned in bug#334533 (comments 8 and 9)...
That bug report is about wrong files getting renamed when using inline rename (in case the list changes during renaming).

But *here* the actual problem IMHO is that inline rename is triggered in the first place, I say it shouldn't.
Comment 3 Wolfgang Bauer 2018-09-19 10:02:56 UTC
(In reply to Wolfgang Bauer from comment #1)
> Btw, I can reproduce the inline rename problem here.
> It only seems to happen when the file was already selected, and I move the
> mouse immediately after pushing down the mouse button without any delay at
> all.

After more testing, I'd say the real trigger is to move the mouse quickly (i.e. before the timeout for inline rename expires) outside of the current view after holding the mouse button.

And it probably doesn't need to be selected first, I just noticed that I cannot trigger inline rename at all for unselected files (another bug/regression it seems).

Btw, this is not related/specific to split view at all, it is also reproducible with a single view, so I'll change the component...

FTR, I'm using the latest Qt5 (5.11.1), KF5 (5.50.0) and dolphin (18.08.1) here.
Comment 4 Wolfgang Bauer 2018-09-19 12:06:47 UTC
PS: I'll also change the summary to what I think is the underlying problem, I hope you agree.
Comment 5 Wolfgang Bauer 2018-09-19 12:44:24 UTC
(In reply to Wolfgang Bauer from comment #3)
> I just noticed that I
> cannot trigger inline rename at all for unselected files (another
> bug/regression it seems).

Hm, after trying older dolphin versions (including the KDE4 based 15.04), it seems that long-clicking on a file in single-click mode is not supposed to trigger inline rename at all.

That this is possible for selected files now is a "regression" of https://cgit.kde.org/dolphin.git/commit/?id=5454283008f26d377a6403861a3cdd7992dbbd38. (which apparently also applies to single-click mode, even though the summary states it's restricted to double-click...)

The mentioned problem when dragging files happens in both single- and double-click mode though, and reverting that commit prevents it.
Comment 6 Wolfgang Bauer 2018-09-19 16:48:56 UTC
Investigated a bit more, here are my findings:
DolphinView::slotTwoClicksRenamingTimerTimeout() only activates inline rename when if m_dragging is not true.
But when this happens, m_dragging is in fact false (although dragging a file is in progress).

The reason is this in DolphinView::eventFilter():
    case QEvent::GraphicsSceneDragLeave:
        if (watched == m_view) {
            m_dragging = false;
        }
        break;

I.e. if you drag a file outside of the view, m_dragging will be set to false again.
I have no idea if that's intentional or a bug though (I don't know what the exact purpose of m_dragging).
If it is how it should be, I suppose the abortTwoClicksRenaming() should be called inside the case statement...
Comment 7 andreas.krutzler 2018-10-03 18:08:25 UTC
Git commit ddfc86ab8c207b81ec9ac83167d081b8d01c2750 by Andreas Krutzler.
Committed on 03/10/2018 at 18:08.
Pushed by akrutzler into branch 'Applications/18.08'.

Fix that dragging a file can trigger inline rename.

Summary:
Inline renaming is aborted as soon as an item is dragged. Previously, ’m_dragging' was used to determine if an item was being dragged. However, inline renaming is triggered after a certain amount of
time, during which time the user may have stopped dragging items.
FIXED-IN: 18.08.2

Test Plan: When dragging an selected item, inline renaming should never be started, regardless of where you drag it (Places panel, other split-view window, out of the Dolphin window, ...).

Reviewers: wbauer, elvisangelaccio, #dolphin, ngraham

Reviewed By: wbauer, elvisangelaccio, #dolphin, ngraham

Subscribers: kfm-devel

Tags: #dolphin

Differential Revision: https://phabricator.kde.org/D15904

M  +3    -2    src/views/dolphinview.cpp

https://commits.kde.org/dolphin/ddfc86ab8c207b81ec9ac83167d081b8d01c2750