Renaming a file is not reflected in the editor when renaming twice to same name different case

[whitefirer]

Does this issue occur when all extensions are disabled?: Yes/No

• VS Code Version: 1.71.2
• OS Version: macOS Monterey 12.5.1 (21G83)

Steps to Reproduce:

1. create file named Test.go
2. rename the file to test.go
3. check the title of the file's editor tab

Is still Test.go, not the new name test.go. until reopen the file.
But test.go rename to Test.go is ok.
Also Foo.go reanme to test.go is ok.
Just Test.go rename to test.go is not ok.

[bpasero]

Can you try to reproduce with our nightly insider builds? You can give our preview releases a try from: https://code.visualstudio.com/insiders/

[whitefirer]

Ok, now it's changed when i use the insider build:
test.go rename to Test.go is not ok.
Test.go rename to test.go is ok.

It seems that some intersting things work wrong here.

[bpasero]

Can you try to run code --disable-extensions --user-data-dir <directory> where <directory> is an empty folder? This will ensure Code is starting with a fresh data directory, e.g. no specific settings and without any extensions running.

[whitefirer]

As you see, nothing changed.

[bpasero]

Hm yeah I think I see it too, the first rename works fine but then renaming back does not work, is that what you see?

[bpasero]

@lramos15 this is a funny one and indeed a regression from our work to always go through the editor resolver when resolving editors and not go through the ITextEditorService as a shortcut.

Steps

• open an empty folder with 1 file Test.go
• open the file
• rename it from the explorer to test.go
• verify the tab label updates
• rename it from the explorer to Test.go
• 🐛 the label does not update

Here is how it used to be

• the rename operation will eventually hit IEditorService.replaceEditors
• since this is a default text editor we would directly use ITextEditorService.createTextEditorInput
• ⭐ we figure out that we have an existing editor input so we do not create a new one however we update its preferred resource here
• this triggers a label change event that will update the tab label

=> this works every time you rename, irrespective of going back and forward of the name

Here is how it is today

• we also end up in IEditorService.replaceEditors
• however we always now go to the editor resolver (which imho is good)
• the editor resolver however does not consider the input to be a new input after the first rename because the canonical resource is still how it was in the begining, it will do an early return here
• 🐛 as such, the inputs preferred resource is never updated

Now I am actually not so sure how to fix this. I am a bit worried that updating the FileEditorInput.matches() method to respect resource path casing may break other behaviour that relies on the current behaviour.

Maybe the resolver should not be so clever to do an early return? Why do we do this?

[lramos15]

Maybe the resolver should not be so clever to do an early return? Why do we do this?

Yeah maybe, I think it was to prevent creating too many inputs and calling unnecessary factories when things are not actually changing at all. I guess we could always remove the early return and see what breaks.

[bpasero]

At least for text file editors, there is caching so that we do not end up with an editor input each time, but I think the same issue already exists today: if you do not have a tab as active and the editor resolver is used to bring up that editor, we would delegate the decision whether to create an editor input or not to the provider and so its up to the provider imho to do the caching.

vscode/src/vs/workbench/services/textfile/common/textEditorService.ts

Lines 246 to 266 in 8b8767e

	private createOrGetCached(
	resource: URI,
	factoryFn: () => TextResourceEditorInput | IFileEditorInput | UntitledTextEditorInput,
	cachedFn?: (input: TextResourceEditorInput | IFileEditorInput | UntitledTextEditorInput) => void
	): TextResourceEditorInput | IFileEditorInput | UntitledTextEditorInput {
	// Return early if already cached
	let input = this.editorInputCache.get(resource);
	if (input) {
	cachedFn?.(input);
	return input;
	}
	// Otherwise create and add to cache
	input = factoryFn();
	this.editorInputCache.set(resource, input);
	Event.once(input.onWillDispose)(() => this.editorInputCache.delete(resource));
	return input;
	}

[lramos15]

Sorry, got caught up in other work and missed this. Will attempt a fix early in debt week for the November release as it is too risky to go in this late