RESOLVED FIXED278721
[GTK] Too many useless MPRIS notifications
https://bugs.webkit.org/show_bug.cgi?id=278721
Summary [GTK] Too many useless MPRIS notifications
Michael Catanzaro
Reported 2024-08-27 05:44:21 PDT
Created attachment 472317 [details] Screenshot of notifications Visit https://www.cnn.com/2024/08/25/us/security-robots-human-guards/index.html and wait about 5 seconds. Notice the page creates an MPRIS notification in the gnome-shell notification area. It's not very useful because it says "Unknown title" and "Unknown artist" so the user has no indication as to what it's for. Now open the same page again in a different tab. This time, I had to wait longer than 5 seconds, but eventually a second MPRIS notification appeared. During normal daily browsing, with a bunch of news websites and reddit open in a bunch of different tabs, it creates a spam of many simultaneous "Unknown title" MPRIS notifications. Each one is useless since there's no way to know what media element the notification corresponds to. The page doesn't even contain any obvious video elements. If I click Play on the notification, nothing seems to happen. I'm not sure what should be changed here. Maybe only create one MPRIS notification per browser instance rather than one per tab, to avoid the spam? Maybe don't create a notification if the video has never been played?
Attachments
Screenshot of notifications (22.12 KB, image/png)
2024-08-27 05:44 PDT, Michael Catanzaro
no flags
Patrick Griffis
Comment 1 2024-08-27 07:51:18 PDT
> I'm not sure what should be changed here. Maybe only create one MPRIS notification per browser instance rather than one per tab, to avoid the spam? Maybe don't create a notification if the video has never been played? It looks like Chromium only shows one for the last one changing state to play. This is a bit weird for WebKit though as each WebProcess exposes itself to MPRIS, not the UI process.
Michael Catanzaro
Comment 2 2026-03-18 11:46:22 PDT
This would help: diff --git a/Source/WebCore/platform/audio/glib/MediaSessionGLib.cpp b/Source/WebCore/platform/audio/glib/MediaSessionGLib.cpp index b5a1ed2b4b0b..b88b5cfcead5 100644 --- a/Source/WebCore/platform/audio/glib/MediaSessionGLib.cpp +++ b/Source/WebCore/platform/audio/glib/MediaSessionGLib.cpp @@ -220,6 +220,10 @@ bool MediaSessionGLib::ensureMprisSessionRegistered() if (!m_connection || mprisRegistrationEligibility() == MediaSessionGLibMprisRegistrationEligiblilty::NotEligible) return false; + const auto& info = nowPlayingInfo(); + if (!info || info->metadata.title.isEmpty()) + return false; + if (m_ownerId) return true; It's just a last-chance check to reject any media session with no title, which GNOME displays as "Unknown Title". In practice, our spammy MPRIS notifications always use both "Unknown Title" and "Unknown Artist", so this eliminates the MPRIS spam. That's definitely not an *ideal* fix, though, because there might be a good media element on the page that really should create an MPRIS notification. I spent about half an hour trying to find our code for deciding which media element should receive the MPRIS session, but failed. But it's not harmful, either; after all, something has already gone seriously wrong if we're trying to display a media session with no title.
Michael Catanzaro
Comment 3 2026-03-19 12:22:14 PDT
EWS
Comment 4 2026-03-20 07:05:49 PDT
Committed 309615@main (d7414b3bdd97): <https://commits.webkit.org/309615@main> Reviewed commits have been landed. Closing PR #60954 and removing active labels.
Radar WebKit Bug Importer
Comment 5 2026-03-20 07:06:14 PDT
Note You need to log in before you can comment on or make changes to this bug.