SUMMARY I am running your browser plugin and integration host executable with GNOME 3.30 as my desktop environment, mainly to control video/audio playback using MPRIS and/or media keys. The integration is started by Firefox and running in the background. Media control is activated in the Firefox addon settings, but media key control does not work (see additional information for details). STEPS TO REPRODUCE 1. On a GNOME + Firefox installation install also the integration 2. Open up a Youtube video and start it 3. Try to control it using the media keys (should work on KDE apparently I guess) OBSERVED RESULT Nothing happens, i.e. video does not respond to play/pause commands. EXPECTED RESULT I would expect it to work even on GNOME desktop environment as this is plugging into the general MPRIS2 DBus API and thus should be recognized by every desktop environment/program that is capable to interface with MPRIS2. (And I really would like to use it as sadly GNOME does not provide me such a nice integration.) SOFTWARE/OS VERSIONS Linux/KDE Plasma: Arch Linux x64, GNOME 3.30.2 (available in About System) KDE Plasma Version: - KDE Frameworks Version: - Qt Version: - ADDITIONAL INFORMATION After debugging the browser extension as a first try to identify the issue I tried to run /usr/bin/plasma-browser-integration-host directly and it is logging an error: > QSocketNotifier: Can only be used with threads started with QThread As far as I can see after some more debugging the application did not receive any JSON messages sent to it by Firefox. I 'fixed' it by replacing the `QApplication` in `main.cpp` by a `QCoreApplication` and removing the `a.setQuitOnLastWindowClosed(false)` call. This does eliminate the error for me and brings the extension to life. However, I do not know the implications of this change regarding the KDE desktop environment.
Thanks for your investigation. A QApplication is required for some of the integration features we have for Plasma. I have noticed when the host prints debug output the browser gets confused and the integration breaks. I wonder why it does that in your case, however.
*** Bug 401651 has been marked as a duplicate of this bug. ***
Looks like qt5ct is causing this. A fix would be for the host to close regular stdout so that nobody but us can print stuff to the browser.
I found that if I install kvantum and use 'export QT_STYLE_OVERRIDE=kvantum' to style qt apps instead of 'export QT_QPA_PLATFORMTHEME="qt5ct"' in .xinitrc, everything works and looks great.
Git commit cf6d43ac605401062d5173e2409d7f244f5cf9f9 by Kai Uwe Broulik. Committed on 03/12/2018 at 16:39. Pushed by broulik into branch 'master'. Install message handler after QApplication When using qDebug et all we will use Connection::self()->sendMessage() to forward that to the browser. Connection uses a QSocketNotifier to listen to browser commands. This requires a working event dispatcher. When someone uses qDebug before QApplication initialized, e.g. qt5ct does this, our QSocketNotifier is defunct and we never receive any commands from the browser, breaking the extension. While stdout is reserved for communcation with the browser, where any random debug output will have the browser shut us down, qDebug prints on stderr which can be used for printing debug output, so no file descriptors are closed to prevent miscommunication. CHANGELOG: Now also works when using qt5ct Differential Revision: https://phabricator.kde.org/D17335 M +2 -2 host/main.cpp https://commits.kde.org/plasma-browser-integration/cf6d43ac605401062d5173e2409d7f244f5cf9f9