WM_CLASS window property on Linux

[jflombera]

Device:

Linux

Operating System Version:

 Debian Stretch  (testing)

Spotify Version:

 1.0.17.75.g8f111100

Description:

 Imposible to match Spotify window when it is created using WM_CLASS propety.  WM_CLASS property is not set early enough at startup.

To reproduce:

 In i3 WM try the following configuration and start spotify:

assign [class="Spotify"] 3

 This should force Spotify to be assigned to workspace 3 but since the class property is not matched, the rule is ignored.

Workaround:

 N/A

Additional information:

 See https://bbs.archlinux.org/viewtopic.php?id=204636

[Adam_B]

Hey @jflombera!

Thanks for posting.

I've moved your issue into the Desktop help area. 

This is the best place to get help and resolve issues in the Linux client.

Thanks again, 

Adam.

[jflombera]

Is there any news regarding this issue? Thanks, Jose

[dekozo]

I`ve been having the same issue.
I am using i3-gaps on Arch linux and my configuration is just the same as yours.
Whenever I run Spotify from dmenu it starts on the current workspace.

[biovgg]

Same issue here. From a workaround in https://github.com/i3/i3/issues/2060 I have been able to get it working.

Changing

assign [class="Spotify"] $workspace10

to 

for_window [class="Spotify"] move to workspace $workspace10

makes the trick. It creates the window in the current workspace and when the class is declared the window is moved.

Note: $workspace10 is the variable in my system, change accordingly with yours. 

[danikron]

I have this problem as well. Using BSPWM on Arch.

Pretty sure this shouldn't have been moved to the Help - Desktop section since it's a bug or an ICCCM noncomplience issue that was introduced with the redesign.

[kamchacta613]

Also experiencing this issue, but with compiz config settings mananger and unity. 

[realchaseadams]

Thanks for sharing the workaround. I, too, found this issue as a workaround and wanted to make sure there was an issue documented with Spotify. Thanks!

[Rypac]

Any updates on this issue? Currently using the workaround (thanks biovgg) but it'd be great to have an actual solution.

[freundTech]

I can confirm that this is still a problem in the current version.

Spotify only sets it's WM_CLASS property after mapping itself, which is against the ICCCM specifications:

---

This property must be present when the window leaves the Withdrawn state and may be changed only while the window is in the Withdrawn state. Window managers may examine the property only when they start up and when the window leaves the Withdrawn state

Changing the class after mapping the window will break a lot of programs, like window managers and taskbars (some of which are mentioned in this thread).

[Dreadlord]

Hey @freundTech,

Let me try to summon @jooon here and see what he can do about that : )

[jooon]

I agree. It makes sense. We are most certainly doing things in the wrong order, which doesn't matter on Win/Mac, but it does on Linux. I can't see it immediately, my CEF/X skills are pretty bad. There is an old internal bug tracking this issue since last year, so at least it is on the todo list.

[freundTech]

Not sure if that helps, but the spotify executable contains a call to XLibs "XSetClassHint()", so I would guess that you (or a statically linked library) are using that to set the WM_CLASS.

[jooon]

Yep. We are setting it in with XSetClassHint in the Spotify code.

I've talked to Marshall, the creator of CEF, and he gave me some pointers. The way we use CEF now, means CEF creates the top-level window, and there is no way to get the window handle after creation and before it is mapped.

https://bitbucket.org/chromiumembedded/cef/src/1c06d8e3f55f21a3c7383e4f99fe30283200f118/libcef/brows...

We will "soon" switch the desktop client to use CEF with the Views architecture instead, which means the Chromium code will create and map the window. With Views there is a way to tell Chromium to set WM_CLASS correctly, by setting some widget parameters.

https://cs.chromium.org/chromium/src/ui/views/widget/desktop_aura/desktop_window_tree_host_x11.cc?q=...

I kind of know how to fix it now in CEF when I have time.

[dqwdqwdqw · Accepted solution]

You can try preloading spotifywm. I hacked it down in an hour and I hope it works.

[Ayydavay]

Hey, I'm a "bit" new to linux and I'm not sure where the spotify binary is in regards to this 

LD_PRELOAD=/usr/lib/libcurl.so.3:/path/to/spotifywm.so /path/to/spotify/binary

 Thank you

[Davvos11]

For me (Arch Linux) /usr/share/spotify/spotify worked

[ignusgracia]

I too have this problem ... looking forward to the official fix since workarounds didn't work for me so far (running Compiz)

[Ekaradon]

Hello @jooon,

I would like to know if this subject could be tackle. Is it still in your todos list? Have you already switch to View Architecture?

Thanks,