vscode: New version 1.69 has missing `app_id` under wayland

Can confirm this issue is still unaddressed in 1.80.0.

Can confirm. When launching VS Code on Wayland with the --enable-features=UseOzonePlatform and --ozone-platform=wayland launch options the running app is displayed as a separate, unstyled app icon in my dock. This is still an issue in v1.69.2

A workaround in KDE Plasma is to define a new window rule that matches window class code-url-handler, and forces the desktop file name (app id) to Code. Feels a bit less hacky than editing the desktop file, and won’t break again when VSCode properly fixes this issue.

Still encountering this issue on 1.86.0-insider.

We’ve fully addressed this issue in the Solus package. The key is to update the .name field in the package.json to match the name of the .desktop file without the .desktop suffix, and to update the .desktopName field to match the full name of the .desktop file including the suffix. The reason this issue occurs is because of the following lines in build/gulpfile.vscode.js:

		// for linux url handling
		if (platform === 'linux') {
			packageJsonUpdates.desktopName = `${product.applicationName}-url-handler.desktop`;
		}

This causes the resulting package.json to be generated with a .desktopName value of code-oss-url-handler.desktop. Electron reads from this field in order to set the app_id under Wayland (it will use the .name field if .desktopName isn’t set) and so the resulting Wayland window will have a code-oss-url-handler app_id. If on the other hand you override these values in the package install phase you can fix the issue:

vsdir=/usr/share/vscode
package_json=$installdir/$vsdir/resources/app/package.json
tmp=$(mktemp)
jq ".name = \"code-oss\"" $package_json > "$tmp" && mv "$tmp" $package_json
jq ".desktopName = \"code-oss.desktop\"" $package_json > "$tmp" && mv "$tmp" $package_json

(Our .desktop file is code-oss.desktop)

As far as I can tell this has no side-effects on our package. VSCode windows startup with the correct app_id and are correctly associated with the .desktop launchers on both GNOME and Plasma.

Hell, it even fixes the “open file/folder” windows opening behind VSCode as they should now start with the correct app_id as well and so correctly be placed in front of the existing VScode window.

VSCode is still reporting its wmclass as code-insiders-url-handler under Wayland and the app shows up as the URL handler. I’ve worked around it by creating ~/.local/share/applications/code-insiders.desktop and setting StartupWMClass=code-insiders-url-handler.

This is a poor solution that only works on GNOME. GNOME adds the value of the StartupWMClass field to the mapping of .desktop files to application windows. This is not standards-compliant and should be considered a hack at best. According to the FreeDesktop standards ONLY the name of the .desktop file is to be considered for window associations and this is how it is implemented on Plasma and wlroots-based compositors. So updating the StartupWMClass would only “fix” it on GNOME, whereas the above solution will fix it on all DEs as it is actually updating the app_id to be the package-specified value.

I can also reproduce it on VSCodium. Also I found as a workaround that changing the codium.deskop (or code.desktop) desktop file’s StartupWMClass to codium-url-handler (or code-url-handler for vscode) “fixes” the problem.

Thanks for creating this issue! It looks like you may be using an old version of VS Code, the latest stable release is 1.69.0. Please try upgrading to the latest version and checking whether this issue remains.

Happy Coding!

I have the same problem of @EncryptedCicada. I set into /home/my-user/.config/code-flags.conf: --enable-features=WaylandWindowDecorations --ozone-platform-hint=auto and when I start vscode from the pinned icon in the bottom bar, it starts a new process called Visual Studio Code - URL Handler. If i edit code.desktop and change theStartupWMClass to code-url-handler, it starts the normal process. But I have to remove/rename desktop entry on each update. It’s a bit annoying. I’m on GNOME 44.2 and vscode 1.79.2

Another way that worked for me is to override the code.desktop and code-url-handler.desktop files.

In ~/.local/share/applications

Have the original code-url-handler.desktop renamed to, for example code-url.desktop

mv code-url-handler.desktop code-url.desktop

Symlink code-url-handler.desktop to code.desktop

ln -s code.desktop code-url-handler.desktop

Set the handler for x-scheme-handler/vscode to code-url.desktop

xdg-mime default code-url.desktop x-scheme-handler/vscode

I had to override those files anyway to add --ozone-platform-hint=auto

Also missing under wayland: wmclass - so the app won’t have an icon.

Do you plan on making a PR to fix the issue upstream?

No, because I’m not familiar with the build system from the perspective of the people who develop VSCode with it. My changes to the package.json happen after the build server is finished building. The .desktopName field also has to match the primary .desktop file that is shipped by the distribution (assuming a build of code-oss or vscodium), so it’s not really something that can just be fixed once and that would fix all distributions since the file name of the .desktop file could easily be different.

		// for linux url handling
		if (platform === 'linux') {
			packageJsonUpdates.desktopName = `${product.applicationName}-url-handler.desktop`;
		}

Presumably this line could be changed to .desktop instead of -url-handler.desktop, though I’m not familiar enough with the build to understand:

• Why it’s this way
• What consequences changing it might have (besides fixing the app_id)

Another approach would be for a VSCode developer to add a post-build step to fix the .desktopName field. This would be sufficient to work around the issue in the official .deb/.rpm/.tar distributions of VSCode, although fixing the code referenced above would probably be the better solution (assuming that whatever that code is trying to work around still works, or even if why that code is that way is still known since it doesn’t have comments indicating why).

If you are on a distribution and that distribution builds code-oss or VScodium please point them to my above comment. They’ll be able to use that information to work around this in their packages.

If you’re a VSCode developer interested in fixing the official distributions I recommend doing the following to test this:

• Use KDE Plasma as GNOME is not standards compliant in this regard
• Hit “Alt + F2” to open krunner
• Type in “Kwin debug console” and hit enter when the entry is shown
• This will open up the kwin debug console which is built-in to Plasma desktop. You can use this to see all window properties, and can see what the current value of the desktopFileName property is when running in Wayland-native mode and what the resourceClass property is when running under xwayland. The values of these needs to be identical and needs to match the name of the VSCode desktop file sans the .desktop extension. If you’ve done this then you’ve fixed this issue on all DEs.

I am using 1.75.0 and still experiencing this issue. When Visual Studio Code is opened under Wayland, it’s another application called “Visual Studio Code - URL Handler” that actually shows up. It is not a huge deal but it’s always annoying to see two identical icons, as well as the window instances under the “URL Handler” on my dock.

Well the issue is a little bit different now. VS Code launches with the flags --enable-features=WaylandWindowDecorations and --ozone-platform-hint=auto albeit after several tries but reports the window title as “Visual Studio Code - URL Handler” instead of just Visual Studio Code. Also, the running application icon is separated from the pinned icon in the gnome dock whereas other pinned applications running just have the same icon with a little dot under the icon to indicate they are running.

same here with the incorrect code-url-handler app_id.

I updated to VS Code v1.71.0 today (with Electron 19) and this still is an issue.

Version: 1.71.0
Commit: 784b0177c56c607789f9638da7b6bf3230d47a8c
Date: 2022-09-01T07:25:10.472Z
Electron: 19.0.12
Chromium: 102.0.5005.167
Node.js: 16.14.2
V8: 10.2.154.15-electron.0
OS: Linux x64 5.19.5-arch1-1
Sandboxed: No

Still an issue, Insiders 1.79.0, GNOME.