[Bug]: WM_CLASS is not set on wayland

[harmathy]

Preflight Checklist

• I have read the Contributing Guidelines for this project.
• I agree to follow the Code of Conduct that this project adheres to.
• I have searched the issue tracker for a bug report that matches the one I want to file, without success.

Electron Version

19.0.8

What operating system are you using?

Other Linux

Operating System Version

ArchLinux

What arch are you using?

x64

Last Known Working Electron version

17.4.10

Expected Behavior

To enable the desktop system to match a window to the respective application, wmclass should be set on properly on wayland, as it does on X11.

Actual Behavior

The wmclass is empty on wayland, which results in the compositor not being able to recognize, which application a window belongs to:

Testcase Gist URL

No response

Additional Information

on electron 17.4.10 wmclass is set correctly

[harmathy]

This might be related to [Bug]: Electron icon shown instead of app's on Wayland #34801

[vially]

This seems to be a duplicate of #33578 which should have been fixed by #34855 but it didn't make it into a stable release yet (although it was back-ported to versions 18, 19 and 20).

[RaisinTen]

@vially this issue seems to be about the wmclass property, not the app_id property which your PR fixed, right?

[vially]

this issue seems to be about the wmclass property, not the app_id property which your PR fixed, right?

This is a bit confusing because WM_CLASS is an X11 concept which does not exist in Wayland. The equivalent of WM_CLASS in Wayland is the app_id property (this page has some more information).

But this issue mentions "WM_CLASS is not set on wayland", which could mean two things:

• the WM_CLASS property is not set when the app is run through XWayland
  e.g.: by running Electron without the --ozone-platform=wayland flag
• the app_id property (which is the Wayland equivalent of WM_CLASS) is not set when the app is running natively on Wayland
  e.g.: by using the --ozone-platform=wayland flag

My previous comment assumed it was the latter, but maybe @harmathy can clarify this a bit.

[harmathy]

In Looking Glass all windows have a wmclass property and in the Desktop Entry Specification there is a StartupWMClass, which has to be set correctly on wayland as well as on X11.

Running on Xwayland an electron window looks like this:

on pure wayland:

I guess, app_id is just mapped to WM_CLASS in GNOME on wayland for backwards-compatibility, but I can't be sure (until #34855 is in a release).

[vially]

Thanks, that makes sense.

I still think this is a duplicate of #33578 so it's worth testing if the issue is still present in the nightly version of Electron (npm install electron-nightly).

If this is fixed in nightly, then it was most likely fixed by #34855 which was backported to versions 18, 19 and 20 so it should be part of their next minor/patch release.

[ckerr]

I agree with @vially that this sounds like #33578; but I'm not positive, so I'll leave this open as blocked/needs-info instead of closing. @harmathy please do try a nightly as Valentin suggested and see if it WfY. Thanks!

[harmathy]

I can confirm, this issue is fixed now!