Created attachment 107900 [details] Screenshot Starting a media player using Firejail will cause the media controls and the media information not to show in the application thumbnail. Tested: VLC, Spotify. The media control plasmoid, however, works fine.
I suspect the PID of the service that owns the mpris service becomes different from the PID that owns the window. Can you check xprop | grep PID and click the window when running in firejail and compare that to qdbus org.freedesktop.DBus / org.freedesktop.DBus.GetConnectionUnixProcessID org.mpris.MediaPlayer2.vlc
(In reply to Kai Uwe Broulik from comment #1) > I suspect the PID of the service that owns the mpris service becomes > different from the PID that owns the window. > > Can you check xprop | grep PID and click the window when running in firejail > and compare that to qdbus org.freedesktop.DBus / > org.freedesktop.DBus.GetConnectionUnixProcessID org.mpris.MediaPlayer2.vlc You're definitely right! With Firejail: $ xprop | grep PID _NET_WM_PID(CARDINAL) = 9 $ qdbus org.freedesktop.DBus / org.freedesktop.DBus.GetConnectionUnixProcessID org.mpris.MediaPlayer2.vlc 8057 Without Firejail: $ xprop | grep PID _NET_WM_PID(CARDINAL) = 8089 $ qdbus org.freedesktop.DBus / org.freedesktop.DBus.GetConnectionUnixProcessID org.mpris.MediaPlayer2.vlc 8089
The question is... what can we do about it? :/ Is Firejail perhaps the parent process of VLC? Then we could maybe traverse the parent tree but I'm not really fond of making this mapping logic even more complex and brittle than it already is.
(In reply to Kai Uwe Broulik from comment #3) > The question is... what can we do about it? :/ > > Is Firejail perhaps the parent process of VLC? Then we could maybe traverse > the parent tree but I'm not really fond of making this mapping logic even > more complex and brittle than it already is. Indeed. I just checked pstree and we have: plasmashell───firejail───firejail───vlc───5*[{vlc}]
Reported to Firejail: https://github.com/netblue30/firejail/issues/1619
There is a related discussion in the Mate community, where it has been proposed to use LOCAL_CLIENT_PID instead of _NET_WM_PID: https://github.com/mate-desktop/marco/issues/301 Posting just for reference, can't judge if that makes any sense.
Thanks That's not a terrible idea, but blindly switching will break just as many places as it fixes. Like smplayer which have mplayer and the GUI as separate processes, but deliberately have a NET_WM_PID which is "faked"
Git commit b485043e5633b9a07e3cc6804a66ddbe2c134583 by David Edmundson. Committed on 26/07/2019 at 09:48. Pushed by davidedmundson into branch 'master'. [platforms/xcb] Use XRES extension to get real window PID Summary: It's increasingly common for apps to be in their own PID namespace. If this is the case, they report a buggy NET_WM_PID on their windows as obviously they don't know their own PID. This patch uses the XResources extension to query the real PID instead of asking the window. This allows the task manager to know the real PID when doing lookups for matching services or showing pulseaudio badges. Querying the NET_WM_PID with the NETWM wrappers remains unchanged, so we still have access to all information should a system need it. Test Plan: The relevant unit test KWindowInfo::testPid() still passes whilst using this new extension. Subscribers: kde-frameworks-devel Tags: #frameworks Differential Revision: https://phabricator.kde.org/D22755 M +1 -1 CMakeLists.txt M +1 -0 src/platforms/xcb/CMakeLists.txt M +36 -0 src/platforms/xcb/kwindowinfo.cpp M +1 -0 src/platforms/xcb/kwindowinfo_p_x11.h https://commits.kde.org/kwindowsystem/b485043e5633b9a07e3cc6804a66ddbe2c134583