Thanks for the bug report, but I cannot reproduce the problem here.

Is the "Paste" action updated correctly in the context menu of Konqueror and FolderView?

Moreover, could you describe the steps in more detail? There are many different ways to "Switch to another folder" - maybe it has to be done in a special way?

Finally, what is the text of the "Paste" action before the "Richt-click, select 'Copy'" step? What is the text after this step, but *before* switching to another directory?

Yes, I get the same behaviour in Konqueror, so the "Paste" action is not updated correctly there either.

Here are the steps in more detail:
1. Start Dolphin. It opens in the home directory.
2. Click on the "Downloads" folder to display its contents.
3. Right-click on any file and select "Copy".
4. Use the "Up" toolbar button to go back up one level
5. Click on the "Documents" folder to display its contents.
6. Right-click anywhere. The context menu contains "Paste Clipboard Contents".

Finally, the text of the "Paste" action before the "Right-click, select 'Copy'" step is "Paste clipboard contents", same as after copy. I had tried purging clipboard history and contents via Klipper, and the text remains "Paste clipboard contents".

Note that if one repeats steps 3-6 from above, the text of the paste action changes to "Paste one file". Once the file is copied, and another file copy attempt is made, it resets to "Paste clipboard contents" again.

Hi, 
(In reply to comment #2)
> Yes, I get the same behaviour in Konqueror, so the "Paste" action is not
> updated correctly there either.
> 
> Here are the steps in more detail:
> 1. Start Dolphin. It opens in the home directory.
> 2. Click on the "Downloads" folder to display its contents.
> 3. Right-click on any file and select "Copy".
> 4. Use the "Up" toolbar button to go back up one level
> 5. Click on the "Documents" folder to display its contents.
> 6. Right-click anywhere. The context menu contains "Paste Clipboard
> Contents".
> 

I followed these instructions precisely in KDE 4.13.0 on Mageia Linux x86-64 5 and I still got "Paste One File" there. So I cannot confirm. I guess I can try running it inside an openSUSE VM.

Regards,

-- Shlomi Fish

Thanks for the update, Vadym, and for testing it, Shlomi!

Some more questions:

(a) What happens if you repeat the steps and select "Paste Clipboard Contents" or press Ctrl+V? I'm asking because the code that is triggered by the "Paste" action is always the same, independent of the text, so this might help to find out if the code that updates the text has a bug, or if copying the file to the clipboard failed.

(b) (Related to (a)): If you repeat the steps, and the context menu shows the wrong text for the "Paste" action, what is shown if you click the Klipper icon in the system tray?

(c) Does the same bug happen if you cut the file, rather than copying it? After cutting, is the icon of the file shown faded in the view?

(In reply to comment #4)
> Thanks for the update, Vadym, and for testing it, Shlomi!
> 
> Some more questions:
> 
> (a) What happens if you repeat the steps and select "Paste Clipboard
> Contents" or press Ctrl+V? I'm asking because the code that is triggered by
> the "Paste" action is always the same, independent of the text, so this
> might help to find out if the code that updates the text has a bug, or if
> copying the file to the clipboard failed.

In that case, I still see the "Paste one file".

> 
> (b) (Related to (a)): If you repeat the steps, and the context menu shows
> the wrong text for the "Paste" action, what is shown if you click the
> Klipper icon in the system tray?
> 
> (c) Does the same bug happen if you cut the file, rather than copying it?
> After cutting, is the icon of the file shown faded in the view?

I cannot reproduce it with "cut" either.

(In reply to comment #4)
> Thanks for the update, Vadym, and for testing it, Shlomi!
> 
> Some more questions:
> 
> (a) What happens if you repeat the steps and select "Paste Clipboard
> Contents" or press Ctrl+V? I'm asking because the code that is triggered by
> the "Paste" action is always the same, independent of the text, so this
> might help to find out if the code that updates the text has a bug, or if
> copying the file to the clipboard failed.
> 
> (b) (Related to (a)): If you repeat the steps, and the context menu shows
> the wrong text for the "Paste" action, what is shown if you click the
> Klipper icon in the system tray?
> 
> (c) Does the same bug happen if you cut the file, rather than copying it?
> After cutting, is the icon of the file shown faded in the view?

(a) After selecting "Paste clipboard contents" I get a prompt "Filename for clipboard contents", even if I had previously multiselected several files.

(b) I see the list of files selected for copying/cutting in reverse order (most recent first) using syntax "file:///...", followed by a menu separator, followed by the standard Klipper menu entries such as "ENable clipboard actions", "CLear clipboard history", etc

(c) Yes, the same bug applies to both cut and copy actions. As to the icon fading after cutting, it behaves "funny". The first time I select cut on a file, the icon fades, then within a second, the fading is gone, and the context menu  after right-clicking shows "Paste clipboard contents". The second time I select cut on that file, the icon fades, and stays faded, and the context menu  after right-clicking shows "Paste one file".

(In reply to comment #6)
> (a) After selecting "Paste clipboard contents" I get a prompt "Filename for
> clipboard contents", even if I had previously multiselected several files.

And what is put into the file if you enter a filename in this dialog?

> (c) Yes, the same bug applies to both cut and copy actions. As to the icon
> fading after cutting, it behaves "funny". The first time I select cut on a
> file, the icon fades, then within a second, the fading is gone, and the
> context menu  after right-clicking shows "Paste clipboard contents".

This shows that the file is cut/copied correctly by Dolphin, and then shortly after that, something else is put into the clipboard. It would be interesting to know what is responsible for this second action - I see no evidence that Dolphin is doing it, and considering that you are apparently the only one who has ever had this problem, I'm starting to wonder if this is really a bug in Dolphin, kdelibs or Qt, or if there is some other application running on your system which updates the clipboard in the background.

Can you reproduce the problem with a new user?

1. If I enter a filename in that dialog, the resulting file on disk contains "file://<full path to the file being copied>".

2. Yes, that sounds like something else is messing with the clipboard contents. 

3. I'll try reproducing the issue with a new user and report here.

Yup, it does not happen with a new user.

I'll try eliminating one by one all the programs that are running (and/or are automatically started at login into KDE when session is restored) to see which one may be the culprit.

Well, this is interesting. If I reboot the laptop, then the problem does not manifest itself after the login into KDE - no matter whether a new user is used or my normal existing user.

But if I suspend/resume several times, then the problem appears - with both new and existing users, even if no autostarted apps like Chrome are running.

Looks like I am not the first person to experience this issue - according to the following, KDE Connect is the culprit (and I do use KDE connect on it).
https://forum.manjaro.org/index.php?topic=6997.0

The problem was that we were writing back to the clipboard the text we just read, but this should be already fixed in the latest versions of KDE Connect.

Can anybody confirm if this still happens with KDE Connect 0.5.2?

Closing as fixed, if problem persists please reopen.

The issue is back again here on Opensuse Leap with updated Plasma (5.6) and kdeconnect 0.9g-3.1

I can confirm the issue is back again. Running updated Arch Linux, Plasma 5.7.3-1 and kdeconnect 0.9.g-3.