Change:
assert.strictEqual(untitledEditorFactoryCalled, 0); assert.strictEqual(diffEditorFactoryCalled, 0); <del> assert.ok(!lastEditorFactoryEditor); </del> assert.ok(!lastUntitledEditorFactoryEditor); assert.ok(!lastDiffEditorFactoryEditor);

Discussion:
<!-- Do Not Delete This! bugreporttemplate --<!-- Please read our Rules of Conduct: --<!-- Read our guide about submitting issues: --<!-- Search existing issues to avoid creating duplicates. --<!-- Test using the latest Insiders build to see if your issue has already been fixed: --<!-- Instead of creating your report here, use 'Report Issue' from the 'Help' menu in VS Code to pre-fill useful information. --<!-- Launch with to check. --Does this issue occur when all extensions are disabled?: Yes/No <!-- If you answered No above, use 'Help: Start Extension Bisect' from Command Palette to try to identify the cause. --<!-- Issues caused by an extension need to be reported directly to the extension publisher. The 'Help Report Issue' dialog can assist with this. --- VS Code Version: 1.71.2 OS Version: macOS Monterey 12.5.1 (21G83) Steps to Reproduce: file named the file to the title of the file's editor tab <img width="199" alt="image" src="https://user-"Is still , not the new name . until reopen the file. But rename to is ok. Also reanme to is ok. Just rename to is not ok.
Can you try to reproduce with our nightly insider builds? You can give our preview releases a try from:
rename to is not ok. rename to is ok. It seems that some intersting things work wrong here.
Can you try to run where 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.
As you see, nothing changed.
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?
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 as a shortcut.

Steps open an empty folder with 1 file open the file rename it from the explorer to verify the tab label updates rename it from the explorer to the label does not update Here is how it used to be the rename operation will eventually hit since this is a default text editor we would directly use we figure out that we have an existing editor input so we do not create a new one however we update its preferred resource 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 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 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 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?
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.
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.
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