New version 1.69 has missing `app_id` under wayland

[aslpavel]

Does this issue occur when all extensions are disabled?: Yes

• VS Code Version: 1.69.0
• OS Version: Linux wayland backend

Steps to Reproduce:

• Under any wayland desktop
• Force wayland backend for vscode

  $ cat ~/.config/code-flags.conf 
  --enable-features=UseOzonePlatform
  --ozone-platform=wayland

• Any top level window under wayland is identified by app_id which used to be equal to "code" and now it is an empty string.

This bug is probably caused by switching to electron 18, https://github.com/electron/electron/issues/33578 app_id is the only real way to differentiate windows under wayland if you are using a tiling window manager and want to pin some applications to some workspaces.

[VSCodeTriageBot]

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!

[alumni]

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

[PHLAK]

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

[PHLAK]

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

[aslpavel]

For me it works but returns code-url-handler as app_id instead of something reasonable like com.microsoft.code or code:

$ swaymsg -t get_tree | grep code
    "app_id": "code-url-handler",

[drakkar1969]

Also not working for me, version 1.71.0 (Electron 19). App ID under GNOME shows up as code-url-handler

[ozls]

Same issue for me. For some time VSCode did not give a correct app id and the icon was unstyled, now (1.71) it gives the code-url-handler app id. Seems like something is changing but it's still not quite right. Can't wait for this to be fixed.

[akhiljalagam]

+1
Still having this issue

Version: 1.73.1
Commit: Unknown
Date: 2022-11-10T06:33:36.290Z
Electron: 19.0.8
Chromium: 102.0.5005.148
Node.js: 16.14.2
V8: 10.2.154.8-electron.0
OS: Linux x64 6.0.10_1
Sandboxed: No

[akhiljalagam]

until this is fixed. instance working for me for_window [instance="code - oss"] opacity 0.92

[blt-r]

Same for me. When launching vscode with --ozone-platform-hint=auto, app_id is set to code-url-handler

[aacebedo]

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

[taidaii]

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.

[C-512L]

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.

[PowerSnail]

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.

[xbb]

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

[busybox11]

Still an issue, Insiders 1.79.0, GNOME.

[Bryan2333]

The problem still exists after I upgraded to 1.79.

[EncryptedCicada]

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.

[claytonwramsey]

Same issue here!

[M4tT3d]

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

[taidaii]

Can confirm this issue is still unaddressed in 1.80.0.

[dblitt]

Still encountering this issue on 1.86.0-insider. 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 copying /usr/share/applications/code-insiders.desktop to ~/.local/share/applications/code-insiders.desktop and setting StartupWMClass=code-insiders-url-handler.

[ReillyBrogan]

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.

[blt-r]

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

[ReillyBrogan]

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.

[xuanruiqi]

This issue is apparent still here.

[Joseph-DiGiovanni]

Wrong app_id is still an issue on 1.90

[arnaudsm]

Still an issue on 1.92.2. VScode is still unusable on Gnome docks under Wayland.