Pasting file in the explorer no longer opens that file in the editor

[klueless-io]

Issue Type: Bug

When I clone a file, the focus for the file has always been the cloned file and so I can start editing that file and straight away.

This behaviour has changed in the last couple of weeks, I have nearly lost valuable code multiple times recently because of this behaviour change and had thought I was doing something wrong, but I have reproduction steps listed below.

I have tested this without extensions turned on code --disable-extensions to rule out issues there.

The following keystrokes (on mac) is a flow that I have been using for years to work on the next (new) class or file in vscode, this flow has recently stopped working as expected.

I have a file opened, I'll call it original.rb and it is finished and I am ready to move onto my next class/file.

Here are the keystrokes and mouse clicks that I do.

Clone the current original.rb file

Command+S        - This saves the file 'original.rb'
Command+Shift+E  - This selects the explorer window
Command+C        - This copies the current file 'original.rb'
Command+V.       - This pastes the current file to 'original copy.rb'

At this point, the focus in the explorer window is the cloned file 'original copy.rb' and up until recently the focus in the editor has also been the cloned file 'original copy.rb'

I now click mouse in the open editor window
Start editing the new file

BUG: This is not the case any more, the original file has the focus in the editor, even though the cloned file has focus in the explorer .

What has happened time-after-time in the last week or two is that I click into the editor with the assumption that I am working on the cloned file, I update it, delete irrelevant methods, add new methods, save my code and then go to run and my build is failing because I was not altering the cloned file, instead I have been destroying the original file.

AutoReveal Settings

I've checked the autoReveal settings to see if there was an issue there, but I can't see any issues.

VS Code version: Code 1.55.0 (c185983, 2021-03-30T16:01:05.981Z)
OS version: Darwin x64 19.6.0

System Info

Item	Value
CPUs	Intel(R) Core(TM) i9-9880H CPU @ 2.30GHz (16 x 2300)
GPU Status	2d_canvas: enabled gpu_compositing: enabled metal: disabled_off multiple_raster_threads: enabled_on oop_rasterization: enabled opengl: enabled_on protected_video_decode: unavailable_off rasterization: enabled skia_renderer: disabled_off_ok video_decode: enabled webgl: enabled webgl2: enabled
Load (avg)	2, 2, 2
Memory (System)	32.00GB (2.09GB free)
Process Argv	-psn_0_53261 --crash-reporter-id 5534e9ef-10e0-4b4d-848e-f05cde38340f
Screen Reader	no
VM	0%

Extensions (19)

Extension	Author (truncated)	Version
vscode-tailwindcss	bra	0.5.10
vscode-postgres	cko	1.1.17
bracket-pair-colorizer-2	Coe	0.2.0
es7-react-js-snippets	dsz	3.1.1
prettier-vscode	esb	6.3.2
auto-rename-tag	for	0.1.6
vscode-hacker-typer	jev	0.1.1
vscode-csharp-snippets	jor	1.1.0
vscode-docker	ms-	1.11.0
csharp	ms-	1.23.9
mssql	ms-	1.10.1
python	ms-	2021.3.680753044
jupyter	ms-	2021.5.702919634
ruby	reb	0.28.1
LiveServer	rit	5.6.1
markdown-preview-enhanced	shd	0.5.17
code-spell-checker	str	1.10.2
vscode-ruby	win	0.28.0
markdown-all-in-one	yzh	3.4.0

A/B Experiments

vsliv368cf:30146710
vsreu685:30147344
python383cf:30185419
vspor879:30202332
vspor708:30202333
vspor363:30204092
vstry914:30276682
pythonvsdeb440:30248342
pythonvsded773:30248341
vstes627:30244334
pythonvspyt875:30259475
pythonvsnew554cf:30281909
pythontb:30283811
openwsldoc:30282072
vspre833:30267464
pythonptprofiler:30281270
vshan820:30276952
pythondataviewer:30285071
vscus158cf:30286554

[isidorn]

I think the gist of the above is:
"Pasting file in the explorer no longer opens that file in the editor"

If that is inded the gist we have changed this on purpose after numerous users complaining about this behaviour. And I agree with them, especially since no other Explorer does this.

Correct me if I wrongly understood the above issue.

[falahati]

It depends on how you use the explorer tho, what I personally do with copy-pasting a file is to clone a file and start editing it; and I think this should be the main use of copy-pasting files for the majority of people. this behavior cost me hours of headache today since I was modifying old files like 10 times just in the last couple of hours and had to revert and copy the changes to the new file each time.

So if this is about people complaining, consider this my complaint against this change, if for no other reason except the fact that this was the behavior for a long time and many of us already have this in muscle memory.

However, regardless of my personal "complain", please make sure that the focus stays on the old file in the tree view if we are staying with this change since it is confusing as hell that we have a file open in the editor but the focus is on the newly cloned file in the tree view

[klueless-io]

If that is indeed the gist we have changed this on purpose after numerous users complaining about this behaviour. And I agree with them, especially since no other Explorer does this.

This way of working has been in place for years, and many people use it. If other people are complaining, then you give them the option via settings to the workflow that suits their needs, you don't just break tried and well worn workflow.

Even now that I know about the issue, I am still copy/pasting and then editing the wrong file because you can't tell that that you are on the wrong file.

And even if I could tell

please make sure that the focus stays on the old file in the tree view if we are staying with this change since it is confusing as hell that we have a file open in the editor but the focus is on the newly cloned file in the tree view

It would still add an extra step to the workflow because now I would have to copy the file and then use my mouse to go and open it as well.

[dalisoft]

Is there any fix to this behavior? I am also stuck to this issue and seems broke my coding

[oliversalzburg]

I'd happily accept that the previous behavior was wrong, but it stood like this for years for people to train themselves on it. The result is pure frustration for those who have adapted to it.

So if this is about people complaining, consider this my complaint against this change, if for no other reason except the fact that this was the behavior for a long time and many of us already have this in muscle memory.

Fully agreed. This change seems to ignore all the people who didn't complain about the status quo 😄

since no other Explorer does this

When you open Windows Explorer and copy/paste a file, the pasted (duplicated) file will be focused.

[isidorn]

Well we focus the duplicated file. We just no longer open it.

[oliversalzburg]

Indeed. I was unclear in what I was seeing. Specifically, if you have the preview panel enabled in Windows Explorer, it will "open" the new file.

I can see that it's not quite the same as opening a document in an editor, but I still feel like it serves as an example of why the old VS Code duplication behavior wasn't completely unexpected.

Similary, when you copy layers in an application like Photoshop or Paint.NET, you will be editing the duplicated layer right after completing the action.

From a user experience point of view, this could be argued either way to be "correct". I would really like to have an option to control this behavior.

[RobertCsordas]

I screw this up every single time. This caused me at least 100 GPU hours wasted last week. Even though I noticed what's happening pretty early, I still can't remember to click the copied file, because it is so counter-intuitive that my brain just can't handle it. Wouldn't it be possible to create an option for configuring it?

[oliversalzburg]

Just train yourself to hit Enter twice after renaming. It will surely have no negative side effects 😄

[RobertCsordas]

The double Enter opens the name changing box once again and does not change the open file.

[akowalsk]

Well we focus the duplicated file. We just no longer open it.

That is precisely the problem. Focusing on the duplicated file is what misleading about what you're actually editing. What explorer are you referring to when the selected file or directory in the tree on the left panel is NOT the one you're seeing on the right?

I too have wasted numerous hours in the past couple weeks editing the original without realizing it after this change was made.

[kakenbok]

I very rarely add to already discussed topics, but this one is pretty annoying. The double "ENTER" may help, but the copied file should not be shown as selected in the editor tree. Thanks for rolling back the new feature and making this a setting ;-)

[AnyhowStep]

I write many test cases in a single day. In the hundreds to thousands.

They're all plain text files with a certain boilerplate format and it's convenient to copy-paste them and tweak a few lines to test potentially troubling edge cases.

At some point, after updating recently, the behaviour changed.
However, in my case, the names of files don't really matter, which makes things worse.

I have found many files where the test case does not match the file name describing it,
because I copy-pasted a file, clicked on the pasted file, renamed the pasted file, then modified the original file instead of the pasted file by accident.

I've been trying to train myself to work around the issue by double checking the name of the editor tab that's focused...
It's not going well. I still mess up a lot.

---

In Visual Studio 2019, if I copy-paste a file, and click on the pasted file (once), it opens the file in the editor and focuses on it.
Then, I can rename the pasted file, and start editing the pasted file without worrying about overwriting the original by accident.

In VS Code, a single click doesn't open and focus on the pasted file.

Sorry

---

[Edit]

Okay, I just paid more attention and in VS 2019, the pasted file is not selected the tree view.
So, this forces me to click on it to rename, which opens the file in the editor and focuses on it.

In VS Code, the pasted file is selected in the tree view.
So, I instinctively hit F2 to rename the file, and expect it to be open and focused in the editor already, which is not the case.

Clicking the pasted file to select it in the tree view (even though it's already selected), does open and focus it in the editor.

[jedwards1211]

@isidorn actually I think the title should be "after copying and pasting a file, it looks like the copy is open, when the original is still open in the editor"

It's a more neutral title because the crux of the problem is that the pasted file looks like it's open, regardless of whether or not VSCode should open the pasted file (I'm aware that they stopped opening pasted files due to annoyance when multiple files were pasted). In Atom for example, if you paste a file, the copy appears but the original remains highlighted, so it doesn't confuse your brain.

we focus the duplicated file

Actually the highlight color seems to indicate selection, not focus. When you click on a file and then use the arrow keys to navigate, the file focused by arrow keys is highlighted with a secondary color (and indeed if you hit enter this file gets renamed):

In contrast, after you paste, the pasted file is highlighted with the primary color and the original is not even highlighted, misrepresenting the current state of the editor:

This is why it continuously fools all of us into thinking the pasted file is open.

If VSCode is not going to open the pasted file, then it should look like this after pasting instead (ignoring git status colors):

[dalisoft]

I would love to see any option to change this behavior like reverting this like before

[mysticatea]

I feel the new behavior is very confused. I have sometimes edited the original file unintentionally.

There are some reasons for this confusion.

• This change was applied silently. People notice it after editing the other file. Surprised.
• The explorer of VSCode selects the new file and unselects the original file in Ctrl+V flow.
  
  Previously this behavior matches the editor pane. Reasonable.
  But now, the explorer and the editor pane move differently. Because the change of the editor pane (of the previous behavior) is not noticeable due to the same file content, this selection move in the explorer is noticeable. And then, even if I click the editor pane (the original file), the explorer continues to focus on the pasted file. It strongly misleads people who know the previous behavior.

[JimmyBanks]

This behaviour is extremely confusing.

The focus in the Explorer is on the new copy, but the focus in the edit pane is on the old file. That is so counter intuitive I cannot believe this was an intentional change.

IMO one of these two options needs to be made default

1. New file is in focus on both Explorer and Edit pane
2. Old file is in focus on both Explorer and Edit pane.

What is the purpose of even having a focus highlight on the Explorer pane, if it isn't to display what file is open?!

[manzoorwanijk]

The new behavior is frustrating. There should at least be a setting to control the behavior, at least when copying and pasting a single file.

[scriptcoded]

Based on the conversation above it seems that putting behavior behind a setting should resolve most peoples issues.

As I mentioned in my duplicate issue, the earlier behavior seems to be controlled by just a few lines of code (e2c5ff9), and I'd assume re-implementing it behind a setting should be a relatively small task. I haven't worked in the VS Code code base before, but I could probably raise a PR if the VS Code team decides to approve the feature.

[jedwards1211]

@scriptcoded but the other thing we should fix in a PR is making the pasted file get the secondary focus color while the file that's open in the editor retains the primary selection color, in the case that the pasted file doesn't get opened.

[oliversalzburg]

@scriptcoded Thanks for linking in this commit. This lead me to the complaint that ultimately caused this change: #117967

After reading that, the new behavior makes more sense to me. If I copy a file from an external location or another instance of VS Code and paste it into the instance of VS Code I'm working in, I wouldn't expect the file to be opened to be honest. Why that would be undesireable might become clearer when copying a very large binary file between workspaces.

I still can't help being confused by the new behavior when duplicating files inside a single VS Code instance though.

[scriptcoded]

@oliversalzburg I think the confusion is primarily due to the file that's being copied is being opened in preview, and is left open when the file is pasted. This ties in to what @jedwards1211 was saying about the different selection colors. If I'm not mistaken the colors actually refer to the state of the selection, which makes the whole thing a bit more complicated.

In the case when a file is pasted, why would the source file remain selected? What happens when you paste a file from an external source, should there be no files highlighted? Suddenly which file is selected in the explorer is dependent on the users preference for whether or not to open the pasted file in a new tab. That seems a bit odd to me.

[isidorn]

Will revert back to the old behavior probably. Assigning to April to investigate.

[jedwards1211]

@isidorn the old behavior was changed primarily because people were getting annoyed when they would paste dozens of files and VSCode would open all of them, right? I guess the rule could be only open if one file is pasted, but I think most of the complaints would die down if just the selection colors after paste are fixed, since it seems like it's uncommon for other IDEs to open a pasted file.

[scriptcoded]

@jedwards1211 Only opening when pasting one file actually seemed to be the old behavior. Also, while I think the selection colors might help, VS Code still has the preview file-feature which makes things confusing. Therefore I think it's important that the setting is there at least.

[jedwards1211]

@scriptcoded you know, we should make a separate selection color issue anyway, because if you copy and paste multiple files, you end up with just one of the copies selected in the navigator but not open in the editor, so there's confusion there too

[jedwards1211]

Okay I opened #122586

[isidorn]

Fixed via ed5d4a1

[Nick-Lucas]

I appreciate this has now been resolved, but most of the discussion I've seen has been dogmatic rather than oriented around workflows. So I wanted to offer a use case (similar to OP) for consideration. Generally I agree that if there's a setting for this the problem should be resolved for all.

I work with C#/.NET in VS Code, as a Mac user. This means when creating new .cs files I don't benefit from the fantastic "New File" experience of full-fat VS, but also don't want to spend time typing up my namespace and imports. CMD+N may also try to create files in the wrong directory based on my currently open file.

So my common workflow has been:

• Pick a file in the namespace where I want a new class
• CMD+C CMD+P Return (enter name) Return Return CMD+C - basically, duplicate the file, rename it, then get the new class name on my clipboard
• Move focus to the editor, paste the class name and delete any existing code from the copied class, so I can start work

Since the (now reverted) change came in I've found myself constantly editing the original file instead of the new file, and later having to switch round the content once I realise my mistake.

It's not lost on me that my use case is basically the embodiment of this XKCD, but given this has been a feature since the early days of VS Code I would definitely like to at least have a setting to return this behaviour for single files!