[regression] Recent list on mac doc doesn't includes folders anymore

[jrieken]

Since a few days the recent list in the doc context menu shows almost no entries and seems to show files only. It used to show folder (that I have opened in the past) and files

[bpasero]

@jrieken the list is driven by the list of recently opened files/folders/workspaces and this list can get cleared, e.g. if you run File > Recently Opened > Clear Recently Opened. Can you check the menu entries to see if they match?

Then, whats the contents of this for you:

• open /Users/<name>/Library/Application Support/Code - Insiders/storage.json
• find the contents under the openedPathsList key

[jrieken]

yep, files, folders and workspaces in there

[jrieken]

excerpt from storage.json (there are a few more but no errors or such)

"openedPathsList": {
        "workspaces2": [
            "file:///Users/jrieken/Code/_samples/virtual",
            "file:///Users/jrieken/Code/vscode",
            "file:///Users/jrieken/Code/vscode-nls-dev",
            "file:///Users/jrieken/Code/gulp-tsb",
            "file:///Users/jrieken/Code/vscode-docs",
            "file:///Users/jrieken/Code/collab/vscode-loader",
            "file:///Users/jrieken/Code/vscode-distro",
            {
                "id": "2fe8841ab3a022a03af35d4afa32766d",
                "configPath": "/Users/jrieken/Code/collab/CollabRemoteHub.code-workspace"
            },
            "file:///Users/jrieken/.vscode-insiders/extensions/ms-vscode.powershell-1.8.3/logs/1534861262-8424461e-55d4-452d-aec7-06d0b5e523bb1534861259950",
            "file:///Users/jrieken/Code/vscode/build/perf",
            "file:///Users/jrieken/Code/vscode-perf-canary",
            "file:///Users/jrieken/Code/vscode-nls-dev-loader",
            "file:///Users/jrieken/Code/_samples/ConsoleAppDnx",
            "file:///Users/jrieken/Code/vscode-nls",
            "file:///Users/jrieken/Code/vscode-tools/extensions",
            "file:///Users/jrieken/Code/collab/VSCodeBeautify",
            "file:///Users/jrieken/Code/collab/node",
            "file:///Users/jrieken/Code/vscode-uri",
            "file:///Users/jrieken/Code/_samples/dummy-extension",
            "file:///Users/jrieken/Code/collab/electron-startup-perf-baseline",
            "remotehub://github.com/Microsoft/vscode/",
            "remotehub://github.com/OmniSharp/omnisharp-roslyn",
            "remotehub://github.com/OmniSharp/omnisharp-roslyn/",
            "remotehub://github.com/OmniSharp/omnisharp-roslyn/src/",
            "remotehub://github.com/OmniSharp/omnisharp-roslyn/test",

[bpasero]

This could be electron/electron#11159 but I will try to reproduce with those data.

[bpasero]

I cannot reproduce this when running out of sources with the provided contents, so this seems to be the same as the reported one.

[jrieken]

Just saying that this used to work just fine for me and has only stopped to work recently

[jrieken]

@bpasero So what is the recommendation to get out of this and how could the change from working to broken be caused?

[bpasero]

@jrieken if you clear recently opened and restart, does it change?

[jrieken]

@jrieken if you clear recently opened and restart, does it change?

Nope - clearing doesn't help still shows just files and only very few of those. This works with 1.26.1, so it must be a regression with 1.27.x

[bpasero]

@jrieken thing is, 1.26.1 and 1.27.x use different application bundle identifiers. The dock contents are (as far as I know) very much bound to the application ID. As an experiment you could try to change the ID (Info.plist) once and then back again (with restarts in between) to see if that causes some kind of cache to clear.

[jrieken]

Changed CFBundleIdentifier with restarts in-between but nothing has changed.

[bpasero]

I need someone from Apple to explain to me how this menu works... I double-checked the changes around https://github.com/Microsoft/vscode/blame/a550394f34888639ff7bb3d5b6742babe46d59f5/src/vs/platform/history/electron-main/historyMainService.ts#L71 and there was no change in this milestone, also the implementation looks fine to me (we only add file paths). So this cannot be a regression from this milestone at least.

[clshortfuse]

I started having an issue after an insider build 1.31.0 up to this commit:

e02e444

Stable version 1.30.1 does not give me an issue.

[bpasero]

@clshortfuse what are your exact steps to reproduce this? remember to start with an empty list (clear it)

[clshortfuse]

Well, Clean Recently Open actually fixed it. Now that I did that, the issue went away.

Perhaps an older Electron format is incompatible with a newer one used 1.31.0? I'm sorry I can't be of more help, but at least we know that resetting the history will possibly fix the issue. Now we'd just have to find out why.

I wasn't paying much attention to my list before, but I believe it did have a reference to folder that no longer exists. I'm not sure if that matters.

[bpasero]

Good hint, I just tried the dock with a deleted folder but it was still working (just not showing the entry for the deleted folder).

[clshortfuse]

I pulled up a comparison of 1.30.1 vs the commit of Insider version I started having issues with. Mac OS X history was indeed changed:

https://github.com/Microsoft/vscode/compare/dea8705087adb1b5e5ae1d9123278e178656186a...e02e44464c02d617b98d0a3265bf5efef7794436#diff-80efc5fed0d5a0ab6253c65b27c1941b

At a glance, and looking at the changed tests, history can be null. Also, there's some interaction with IEnvironmentService and ILabelService (now getSimpleWorkspaceLabel).

I wouldn't be surprised if it's either of the new functions (getSimpleWorkspaceLabel or getPathLabel) trying to get a label for a workspace folder that has been deleted.

Edit2: GitHub's comment doesn't like putting #diff links. Here's the commit: f041bc0

Edit: It could also have been the change to use coalesce instead of filter here: 0928a6d

[bpasero]

I would think that should not have changed much, e.g. for a file/folder we still use its basename.

At a glance, and looking at the changed tests, history can be null

Where do you see that?

[clshortfuse]

@bpasero bec9357

From what I'm reading, the change is instead of expecting a string array, it's an Array of (string | null). That's what would lead me to believe there was a format change which leads to a compatibility issue.

There's also the possibility that my history list was faulty in 1.30.1. Perhaps it added an invalid (perhaps null value), which 1.31 doesn't produce anymore. Maybe what's happening is that 1.31 is no longer expecting an invalid value in the history and aborting the whole procedure when it does. Darn, now I wish I had saved my history file. :-/

[bpasero]

@clshortfuse well I do not really see invalid values being added. To check, simply trace any usage of app.addRecentDocument in historyMainService.ts. This is the call that will add entries to the macOS dock. I only see calls with using originalFSPath() that never returns null and would throw an error if it was null in the first place.

This leads me to believing that it is an issue with macOS rather than VSCode.

[clshortfuse]

@bpasero When I first had the issue I had 1.30.1 stable (with its blue icon) working fine, but 1.31 Insider (green) not adding entries. It would cancel out the possibility of it being an OS issue if, at the same time, on version didn't have an issue while the other did. When I upgraded the stable build past 1.31, then both stopped working.

this.labelService.onDidRegisterFormatter(() => this._onRecentlyOpenedChange.fire()); was removed.

But _onRecentlyOpenedChange should still be fired eventually by onWorkspaceSaved.

My stable is actually showing some issues right now and I haven't cleared the Recent list.

There are entries in File=>Open Recent lists 5 workspaces and 7 files, while the Dock only lists 2 folders and no files. The 3 that aren't in listed in the dock are because they no longer exists.

When I opened a new workspace (folder), Recents shows 6, and Dock shows 3. But still, none of the files are being listed in Dock. I haven't cleared anything yet, so we may be able to diagnose something. My guess is Electron/VS thinks the dock is full (reached max entries), but isn't accounting for Mac OS X is filtering out nonexistent folders/files.

Edit: I figured it out. I used to have a nonexistent file at the top of the File => Recents list. When I clicked it, VSCode told me the file doesn't exist and removed it from the Recent list. After that, it seems it was removed from the Recents list. Now the Dock is showing all the files (as in Recents) that were under that nonexistent file.

What's happening is either Electron, or Mac OS X, when it encounters a recent entry for a file/folder that doesn't exist doesn't process anything that happens after. This is on 1.31.1 Stable.

Edit2: Messing around, opening a file in VSCode, closing it, then deleting the folder it was in in Finder, then trying to quit VSCode, I managed to crash it:

Exception Type:        EXC_BAD_ACCESS (SIGSEGV)
Exception Codes:       EXC_I386_GPFLT

Edit3: Okay, I broke my recently cleared Insider build, the topmost workspace doesn't show up in Recents doesn't show up in the Dock, after all the creating and deleting shenanigans. And that folder exists because that's what I had opened when I was creating and deleting files. I'm trying to get a set of reproducible actions, but it's definitely related to nonexistent files.

[clshortfuse]

Mac OS X won't add URLs that don't exist to Dock if using noteNewRecentDocumentURL which I can confirm is what Electron does: https://github.com/electron/electron/blob/6da939629b490e0a76d7a451bb9fb5ab4a0a1729/atom/browser/browser_mac.mm#L49

VSCode thinks it has reached MAX_ENTRIES simply because it assumes calling app.addRecentDocument will guarantee an entry and that's not the case. If you want to add an item that doesn't exist, you have make it a menu item instead, as answered in this Stackoverflow question.

I still found some peculiarities, but I think checking for the file to exist before adding to the Dock would be the first step.

[bpasero]

@clshortfuse good point, yeah this could be an explanation for some of the issues we are seeing, not sure if all. Definitely worth to see if we can check the file for existence before adding it.

@jrieken for you, clearing the list of recently opened did not help right?

[jrieken]

@jrieken for you, clearing the list of recently opened did not help right?

That's a long time ago... Not sure anymore, I do remember tho that it once recovered after a restart. Currently I am in a state where it shows something which is a mixture of stale and recent files/folders

[bpasero]

@jrieken stale meaning they are not in the list of recently opened (e.g. from the File menu)?

[jrieken]

No, file menu is correct but the dock menu is doing something else

[bpasero]

Ok I think this is the issue we still have no real understanding about. I can at least look into not adding dock entries that do not exist on disk.

[bpasero]

Pushed a fix to not add paths to the dock that do not exist on disk, this seems to work much better.

[PeterRock]

It can not work again
#69754