Opening a workspace that uses a FileSystemProvider extension for its open files initially adds '(read-only)' suffixes to tab labels

[gjsjohnmurray]

Issue Type: Bug

This issue does not occur in 1.42.1

To reproduce:

1. Clone vscode-extension-samples and open fsprovider-sample.
2. Run this sample.
3. In Extension Development Host run the MemFS: Setup Workspace command followed by MemFS: Create Files
4. Open one of the files, for example file.ts
5. Save the workspace
6. Close the workspace
7. Reopen the workspace. Observe how the file that had been open when the workspace was closed gets its tab restored but with the '(read-only)' suffix.

Ignore the fact that the tab disappears almost immediately. This is a consequence of the MemFS filesystem not being a persistent one, meaning that the restore logic is unable to restore contents for the file.

When tested with a FSP that accesses persistent storage, the previously-open file gets correctly reloaded. The spurious '(read-only)' suffix on the tab label disappears when the tab is clicked on.

I think the bug arises because the extension that implements the scheme specified by the restored file's URI hasn't yet been activated by the time this code gets called:

vscode/src/vs/workbench/common/editor.ts

Lines 690 to 692 in 77dcee2

	if (!this.fileService.canHandleResource(this.resource)) {
	return true; // resources without file support are always readonly
	}

But I haven't yet discovered what changed in 1.43 to cause this regression.

VS Code version: Code - Insiders 1.43.0-insider (17c6d12, 2020-02-28T12:46:02.355Z)
OS version: Windows_NT x64 10.0.18363

[gjsjohnmurray]

Based on #48259 (comment), pinging @bpasero and @isidorn

[bpasero]

Yeah I think we are just missing to listen for capability changes. One change that happened from previous release is that we consider a file editor as readonly if no provider is registered.

[gjsjohnmurray]

@bpasero thanks for fixing this so quickly. I have confirmed that an OSS build from master just now has resolved the issue for my FSP as well. Any chance of it being a Candidate for 1.43?

[bpasero]

Thanks for verifying, I do not think this qualifies as a backport fix to be honest but I could be convinced if there is good reasoning.

[gjsjohnmurray]

Scenario is that a user has a workspace that gets files through a FSP extension (e.g. Remote FS). Then the 1.43 update lands. When VSCode reloads I suspect the tabs of all the open files will show the '(read-only)' suffix. Actually the files are still editable, and clicking on a tab will correct all the labels. But it's not going to be an encouraging first encounter with 1.43.