Custom text editors: backups open 2 editors when restoring

[bpasero]

Steps to Reproduce:

1. install hediet.vscode-drawio extension
2. create a new draw IO diagram
3. make it dirty
4. reload window

=> 🐛 you end up with 2 editors open, but you cannot open the second one

@lramos15 assigning you as well because I think this should be looked at in the context of cleaning up how custom editors are handled in backupRestorer.ts

I had a quick look at this and it looks like the issue is with the ensureDirtyFilesAreOpenedWorker in textFileEditorTracker.ts

private readonly ensureDirtyFilesAreOpenedWorker = this._register(new RunOnceWorker<URI>(units => this.ensureDirtyTextFilesAreOpened(units), 50));

Changing the timeout from 50 to 500 seems to resolve the problem. My guess is that it takes longer for a more complicated editor like drawio to draw and enough time passes for the ensureDirtyFilesAreOpenedWorker to fire and re-add the same file/editor as a new tab.

The only problem is I'm not sure what the best length of time for the timeout should be considering other (potentially more complex) editors - it would probably be better to start the ensureDirtyFilesAreOpenedWorker once the initial editorGroup layout has been completely loaded.

I've made a first attempt at fixing this issue, see draft PR above. Does this seem like the right approach? If so, I'll add some tests and put the PR out for review.

[bpasero]

@scottyjoe9 I looked closer at your fix and think it is going into the right direction, thanks. However, the more I think about it, the more I see a bigger issue with how certain components seem to await the editors from having fully restored before functioning properly, e.g. this one:

vscode/src/vs/workbench/browser/parts/editor/editorsObserver.ts

Line 72 in 763e089

this.editorGroupsService.whenRestored.then(() => this.loadState());

This one is actually ending up being used here:

vscode/src/vs/workbench/services/editor/browser/editorService.ts

Line 957 in c72d761

return this.editorsObserver.hasEditor(this.asCanonicalEditorResource(editor.resource));

And since the custom editor has not restored, the check returns false here:

vscode/src/vs/workbench/contrib/files/browser/editors/textFileEditorTracker.ts

Line 68 in de50318

if (this.editorService.isOpen({ resource })) {

So we end up opening the editor.

I will look into a different fix that tries to tackle the issue at the root: I don't think anyone should be waiting for an actual editor to be restored because that can potentially take a long time.

Ok no problems, thanks for the explanation. It did feel like a bit of a bandaid to some deeper issue but this code base is new to me so I wasn't sure. I'll be interested to see how you solve the problem!