Created attachment 463428 [details] Screencast for this bug - System Information * ArchLinux stable repo * Epiphany 43.0, WebKit 2.38.1 * GNOME Shell 43.0 I reported this issue in epiphany, and I was told it is a webkit's issue. - Bug summary When I browse the web in epiphany, some sites cause a lot of media notifications in gnome-shell (more than one per site). Some sites have no any media player at all. - Steps to reproduce 1. Open Epiphany 2. Browse in site with media and listen to music (in youtube for example) 3. Open sites with no media, like https://rotter.net/, and then you see a lot of media notifications in gnome-shell - What happened A lot of media notifications were created, for no reason. - What did you expect to happen Only sites with media need media notifications, and only once per site. See the attached screencast.
On top of this, the notifications are also somehow leaked. GNOME continues to display the notifications even long after Epiphany is closed. I'm attaching a screenshot as proof, showing three "Kellyanne Conway" MPRIS notifications left alive after I had previously visited https://www.cnn.com/2022/11/28/politics/kellyanne-conway-meeting-january-6-committee/index.html. We should probably turn off MPRIS entirely until we have time to investigate this further, because the user experience is worse than no MPRIS. It's taking up too much space in the notification area.
Created attachment 463794 [details] Another screenshot, these notifications persist after the browser is closed
(In reply to Michael Catanzaro from comment #2) > Created attachment 463794 [details] > Another screenshot, these notifications persist after the browser is closed So you have webkit processes still alive? These aren't notifications, they are dbus services, they should disappear when the process dies.
(In reply to Patrick Griffis from comment #3) > So you have webkit processes still alive? Maybe, but that would imply that we have a web process leak. Well, users *have* been complaining about this happening, so I wouldn't be surprised.... I guess let's focus this bug on limiting MPRIS to (a) only appear when the page actually has real media that is actually playing, and (b) only once per page. Currently I have one Element tab open that is playing zero videos, but it has created five MPRIS notifications. All five notifications are broken: pressing the play button doesn't do anything. Who knows what media elements they supposedly correspond to.
I think its reasonable to disable by default for now. I've also hit some of these issues.
Looks like MediaSessionManagerGLib is designed to own multiple MediaSessionGLibs at once, and each MediaSessionGLib creates a MPRIS notification for as long as it exists. This was redesigned in bug #230250 and has probably been broken since then, but obscured by the D-Bus name issues.
So I think MediaSessionManagerGLib needs to track which media session is the best, and tell each MediaSessionGLib that it owns whether to register or unregister its MPRIS interface accordingly. That should get us down to only one broken notification per tab. (Currently I have 10 broken MPRIS notifications, five for each of two Element tabs, and seeing 2 broken notifications is a lot better than 10.) That won't fully solve the bug, of course, because we should not show any broken MPRIS notifications. But one thing at a time.
(In reply to Michael Catanzaro from comment #4) > Maybe, but that would imply that we have a web process leak. Well, users > *have* been complaining about this happening, so I wouldn't be surprised.... OK, I noticed today that I had a bunch of MPRIS notifications hanging around even though no applications using WebKit were running, and finally checked this out. I noticed three different hung web processes, alive after the UI process exited. I killed them using core signals and examined the backtrace using flatpak-coredumpctl. Two of them were the same bug, which I'll report in bug #247057. The other one was a different bug; I didn't properly save that one, and will have to report it separately next time I see it. So let's handle the web process hangs elsewhere, and save the rest of this bug report for dealing with MPRIS. I don't have time to investigate and fix things properly right now, but I could post a hack patch to just sabotage MediaSessionGLib and avoid the immediate problem. Carlos Garcia doesn't generally like it when I do that, though. :)
I don't see how the ImageDecoder would trigger MPRIS notifications TBH.
(In reply to Philippe Normand from comment #9) > I don't see how the ImageDecoder would trigger MPRIS notifications TBH. It doesn't. There are three problems discussed in this bug report: 1. Bug #247057 is causing the MPRIS notifications to survive after the UI process quits. We can worry about that separately. 2. From comment #7: "I think MediaSessionManagerGLib needs to track which media session is the best, and tell each MediaSessionGLib that it owns whether to register or unregister its MPRIS interface accordingly. That should get us down to only one broken notification per tab." 3. Don't show any broken MPRIS notifications in the first place. If the rewind, play, fast forward buttons do not work, just don't show it. I have 9 MPRIS notifications currently, presumably corresponding to unknown media elements, and none of the buttons do anything. Might need to take heuristics from other browsers, like Firefox.
I think the best short-term thing to do, so close to the release, is to add a websetting for this feature and disable it by default...
Makes sense, but note this feature has been enabled by default since 2.36.4 (241579@main) so I suppose we should disable it on the stable branch too.
(In reply to Michael Catanzaro from comment #12) > Makes sense, but note this feature has been enabled by default since 2.36.4 > (241579@main) As experimental feature. It was truly enabled by default only a couple months ago afaik.
(In reply to Philippe Normand from comment #13) > (In reply to Michael Catanzaro from comment #12) > > Makes sense, but note this feature has been enabled by default since 2.36.4 > > (241579@main) > > As experimental feature. > > It was truly enabled by default only a couple months ago afaik. See 250153@main
Oh you're right, but that's still in 2.38. I will push a commit there to disable it.
So Phil created https://github.com/WebKit/WebKit/pull/8358 for main. And I landed https://github.com/WebKit/WebKit/commit/9a224f3ed860757adc2f8ee13423b4dd45c78737 for 2.38.
Pull request: https://github.com/WebKit/WebKit/pull/26367
Committed 276591@main (5e2b534ceb82): <https://commits.webkit.org/276591@main> Reviewed commits have been landed. Closing PR #26367 and removing active labels.
<rdar://problem/125293330>