Bug 359567

Created attachment 97294 [details]
KWin output when Spotify is being started and stopped

Forgot the mention that I can always reproduce this regardless of the "OpenGL interface" (i.e. EGL or GLX). The attached log is with EGL, though.

can you please provide the xprop output when clicking the spotify window?

Created attachment 97295 [details]
xprop output when clicking the spotify window

Sure. However this is the output *after* the compositor is already suspended, because it happens before the actual appearance of Spotify's window.

I knew that Spotify is using Chromium now, but I've ruled out Chromium
to be responsible for this, because suspend doesn't happen when I start
Chromium, Chrome or some Chrome app (like SlackDeck for example).

However, I've just learned that Spotify is NOT a Chromium app, but uses
Chromium Embedded Framework[1]. According to what I've been able to find
the Steam client for Linux is also using CEF.

Starting Steam involves updating (if not already up-to-date), logging in
(if not already), before showing the actual client. The first two
windows cause exactly the same issue:

1. Start Steam for the first time since weeks (i.e. it's not up-to-date)
2. Starts updating, showing a small window it a progress bar.
3. Composite goes to suspend.
4. I resume it with a shortcut.
5. Update is complete and login window is being showed.
6. Composite goes to suspend.
7. I resume it with a shortcut.
8. Successful login leads to opening the actual client window, *without*
   suspending the compositor.

Once updated, if I simply start it (i.e. already logged in and
up-to-date) it goes directly to step 8 and everything is fine. However
if I log out, stop the client and try starting it again (i.e. still
up-to-date, so steps 2, 3, 4 are omitted), the compositor gets suspended
because of the login window.

I will attach the output from xprop when clicking on the Steam's login
window. Could it be that something in CEF is causing this?

[1] https://en.wikipedia.org/wiki/Chromium_Embedded_Framework

Created attachment 97296 [details]
xprop output when clicking the Steam's login window

What's your frameworks version?

5.19.0

To rule out the obvious: you do not have any rules to block compositing which might (accidentally) apply here?
(please attach ~/.config/kwinrulesrc in doubt)

Created attachment 97297 [details]
~/.config/kwinrulesrc

No, but I use rules for sending particular windows to exact desktops and Spotify is one of them. What I've tried is to force-fully disable blocking composition for Spotify. (i.e. blockcompositing=false and
blockcompositingrule=2), but it doesn't seem to change anything.

I assume it doesn't help, because this option applies too late, since compositor is getting suspended before the actual appearance of the window and compositor is already suspended.

It's probably this rule:

Description=Football Manager 2016
blockcompositing=true
blockcompositingrule=2
clientmachine=localhost
clientmachinematch=0
wmclass=
wmclasscomplete=false
wmclassmatch=1


Notice that "wmclass" is empty.
(This also means that spotify resp. CEF illegally change the class after mapping the window ... *sigh*)

=> try to disable that rule and see what happens.

Thomas, you're right. I'm manually blocking the compositor and then complaining why it blocked.

http://i.lvme.me/sgl679d.jpg

It's not exactly your fault either.

a) Does that "Football Manager 2016" client never sport (pun intended) a WM_CLASS hint, or did you set it empty manually (because it also adds WM_CLASS late)?
b) The pretty much means CEF is setting WM_CLASS after the map request, what's rather an icccm violation

Strictly spoken though, it must be set as long as the window is withdrawn, maybe they keep it that state until it gets actually mapped (while that's not helpful ;-)

=> We might have to sync after mapping the window and before applying the rules?
Can you try a patch (for kwin) - doesn't make sense to relax things here if the client sets WM_CLASS some seconds later.

> a) Does that "Football Manager 2016" client never sport (pun intended)
> a WM_CLASS hint, or did you set it empty manually (because it also
> adds WM_CLASS late)?

It doesn't detect it. Even now when I try to create a new rule for it, I
get these lines via the "Detect window properties" button:

    wmclass=
    wmclasscomplete=false
    wmclassmatch=1

> b) The pretty much means CEF is setting WM_CLASS after the map
> request, what's rather an icccm violation
>
> Strictly spoken though, it must be set as long as the window is
> withdrawn, maybe they keep it that state until it gets actually mapped
> (while that's not helpful ;-)
>
> => We might have to sync after mapping the window and before applying
> the rules? Can you try a patch (for kwin) - doesn't make sense to
> relax things here if the client sets WM_CLASS some seconds later.

I'm currently running a KWin from an offical Arch Linux package, but I
could try applying a patch and compiling kwin, as long as I can apply it
on top of the 5.5.4 tag.

The detection will be fine. The client simply does not set a WM_CLASS hint, so it's kinda "indetectable" :-(

This patch may hunk but should apply to 5.4 (otherwise please ask back)
If CEF is *not* violating the spec, your hyperactive rule should not apply to spotify anymore.

But if it's this https://aur.archlinux.org/packages/spotify/ , I could just test it myself (the CEF thingy is somehow statically linked? I don't see relevant deps)

-----

diff --git a/manage.cpp b/manage.cpp
index 4198e60..41636be 100644
--- a/manage.cpp
+++ b/manage.cpp
@@ -627,6 +627,10 @@ bool Client::manage(xcb_window_t w, bool isMapped)
     } else
         updateVisibility();
     assert(mapping_state != Withdrawn);
+
+    xcb_connection_t *c = connection();
+    free(xcb_get_input_focus_reply(c, xcb_get_input_focus(c), nullptr));
+
     m_managed = true;
     blockGeometryUpdates(false);

Okay, I will be able to try this tomorrow and report if the issue is fixed.

> But if it's this https://aur.archlinux.org/packages/spotify/ , I could just test it myself (the CEF thingy is somehow statically linked? I don't see relevant deps)

Yes, this is the package that I'm using. If it's packaging issue, I will contact the package owner with a fix.

No packaging issue - I installed spotify and can confirm that rules don't apply. Testing now whether an explicit sync between map and ruling helps. If not, it's a CEF bug.

"nope" - WM_CLASS remains empty despite map & sync.
=> Spotify/CEF bug (icccm violation)