WebKit Bugzilla
New
Browse
Search+
Log In
×
Sign in with GitHub
or
Remember my login
Create Account
·
Forgot Password
Forgotten password account recovery
RESOLVED FIXED
278721
[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
Details
View All
Add attachment
proposed patch, testcase, etc.
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
Pull request:
https://github.com/WebKit/WebKit/pull/60954
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
<
rdar://problem/173000652
>
Note
You need to
log in
before you can comment on or make changes to this bug.
Top of Page
Format For Printing
XML
Clone This Bug