Summary: | [GLib] Media session manager unable to handle more than one session | ||||||
---|---|---|---|---|---|---|---|
Product: | WebKit | Reporter: | Philippe Normand <pnormand> | ||||
Component: | Platform | Assignee: | Philippe Normand <pnormand> | ||||
Status: | RESOLVED FIXED | ||||||
Severity: | Normal | CC: | aperez, benjamin, cdumez, cmarcelo, crzwdjk, eric.carlson, ews-watchlist, glenn, jer.noble, peng.liu6, philipj, sergio, webkit-bug-importer | ||||
Priority: | P2 | Keywords: | InRadar | ||||
Version: | WebKit Nightly Build | ||||||
Hardware: | Unspecified | ||||||
OS: | Unspecified | ||||||
See Also: |
https://bugs.webkit.org/show_bug.cgi?id=231811 https://bugs.webkit.org/show_bug.cgi?id=247527 |
||||||
Attachments: |
|
Description
Philippe Normand
2021-09-14 04:08:43 PDT
Created attachment 438586 [details]
Patch
Comment on attachment 438586 [details] Patch View in context: https://bugs.webkit.org/attachment.cgi?id=438586&action=review > Source/WebCore/platform/audio/glib/MediaSessionGLib.cpp:50 > + return { }; Do you mean `return std::nullopt;` here? > Source/WebCore/platform/audio/glib/MediaSessionGLib.cpp:117 > + return { }; Ditto. > Source/WebCore/platform/audio/glib/MediaSessionGLib.h:37 > + explicit MediaSessionGLib(MediaSessionManagerGLib&, GRefPtr<GDBusConnection>&&, MediaSessionIdentifier); Do we need explicit here? Comment on attachment 438586 [details] Patch View in context: https://bugs.webkit.org/attachment.cgi?id=438586&action=review >> Source/WebCore/platform/audio/glib/MediaSessionGLib.cpp:50 >> + return { }; > > Do you mean `return std::nullopt;` here? Why? What would be the difference? Comment on attachment 438586 [details] Patch View in context: https://bugs.webkit.org/attachment.cgi?id=438586&action=review >>> Source/WebCore/platform/audio/glib/MediaSessionGLib.cpp:50 >>> + return { }; >> >> Do you mean `return std::nullopt;` here? > > Why? What would be the difference? Just a style thing. I have seen a lot of usages of `std::nullopt`. Comment on attachment 438586 [details] Patch View in context: https://bugs.webkit.org/attachment.cgi?id=438586&action=review >> Source/WebCore/platform/audio/glib/MediaSessionGLib.h:37 >> + explicit MediaSessionGLib(MediaSessionManagerGLib&, GRefPtr<GDBusConnection>&&, MediaSessionIdentifier); > > Do we need explicit here? Never hurts :) Committed r283437 (242424@main): <https://commits.webkit.org/242424@main> All reviewed patches have been landed. Closing bug and clearing flags on attachment 438586 [details]. This appears to have caused a number of regressions, (list filtered to what I think could be related to the change): Regressions: Unexpected text-only failures media/audio-background-playback-playlist.html [ Failure ] media/media-session/actionHandlerInternalMappings.html [ Failure ] media/media-session/default-actionHandlers.html [ Failure ] media/video-background-playback.html [ Failure ] media/video-concurrent-playback.html [ Failure ] media/video-interruption-with-resume-not-allowing-play.html [ Failure ] media/video-multiple-concurrent-playback.html [ Failure ] media/webaudio-background-playback.html [ Failure ] webrtc/concurrentVideoPlayback2.html [ Failure ] Regressions: Unexpected timeouts media/media-session/callActionHandler.html [ Timeout ] media/media-session/play-after-seek.html [ Timeout ] media/remote-control-command-is-user-gesture.html [ Timeout ] media/remote-control-command-scrubbing.html [ Timeout ] media/remote-control-command-seek.html [ Timeout ] media/video-inactive-playback.html [ Timeout ] media/video-interruption-with-resume-allowing-play.html [ Timeout ] media/video-isplayingtoautomotiveheadunit.html [ Timeout ] media/video-system-sleep.html [ Timeout ] webaudio/audiocontext-state-interrupted.html [ Timeout ] webaudio/suspend-context-while-interrupted.html [ Timeout ] I can't reproduce this on my desktop... I can't reproduce it locally either but it seems to happen consistently on the bots, e.g. https://build.webkit.org/results/GTK-Linux-64-bit-Release-Skip-Failing-Tests/r284248%20(2041)/results.html |