Summary: | REGRESSION (Safari 15?): Blob videos slow to pause, affects CBS and CNN | ||||||||||
---|---|---|---|---|---|---|---|---|---|---|---|
Product: | WebKit | Reporter: | Jeff Johnson <opendarwin> | ||||||||
Component: | Media | Assignee: | Peng Liu <peng.liu6> | ||||||||
Status: | RESOLVED FIXED | ||||||||||
Severity: | Normal | CC: | bfulgham, eric.carlson, ews-watchlist, glenn, jer.noble, peng.liu6, philipj, sergio, webkit-bug-importer | ||||||||
Priority: | P2 | Keywords: | InRadar | ||||||||
Version: | Safari 15 | ||||||||||
Hardware: | All | ||||||||||
OS: | All | ||||||||||
Attachments: |
|
Description
Jeff Johnson
2021-12-08 19:52:43 PST
I've tested with Safari 14.1.2 on macOS 10.15.7, and I can't reproduce on that configuration. The issue occurs with pretty much any video on https://detroit.cbslocal.com, but you may have to sit through an advertisement on that site first to get to the main video, sorry. Question: I'm trying to debug this, and I enabled Media Logging in the web inspector, but it appears that the ALWAYS_LOG messages in PlatformMediaSession.cpp are not logged, because it has a logClassName() of "PlatformMediaSession", as opposed to "MediaSession", is that correct? (In reply to opendarwin from comment #3) > Question: I'm trying to debug this, and I enabled Media Logging in the web > inspector, but it appears that the ALWAYS_LOG messages in > PlatformMediaSession.cpp are not logged, because it has a logClassName() of > "PlatformMediaSession", as opposed to "MediaSession", is that correct? Those are logged as `MediaElementSession` because that is the most derived class, so its `logClassName()` wins. (In reply to Eric Carlson from comment #4) > (In reply to opendarwin from comment #3) > > Question: I'm trying to debug this, and I enabled Media Logging in the web > > inspector, but it appears that the ALWAYS_LOG messages in > > PlatformMediaSession.cpp are not logged, because it has a logClassName() of > > "PlatformMediaSession", as opposed to "MediaSession", is that correct? > > Those are logged as `MediaElementSession` because that is the most derived > class, so its `logClassName()` wins. Does that mean the messages should appear in the log, or not? I'm not seeing them, unless I misunderstand the source code flow. Unfortunately I'm finding it very difficult to debug the built WebKit source, because run-safari doesn't work right (sandboxing?), the MiniBrowser runs incredibly slow with video, I'm not sure what it's video autoplay policy is, and it also keeps crashing for some reason. Could you clarify the reproducing steps? Is the video slow to response to user's click after the steps? There is a recent fix regarding the performance of blob video loading (bug #234940). Not sure it is related to this bug though. (In reply to Peng Liu from comment #6) > Could you clarify the reproducing steps? Is the video slow to response to > user's click after the steps? I'm not sure what you mean with regard to user clicks. The bug is the overly long time between when HTMLVideoElement.pause() is called and when the video actually pauses. The user could trigger pause() with a click, but that's not essential. OK. Regarding the reproducing steps, I guess you meant the time between the following two event is a few seconds: - The console outputs "pause blob: ****". - The video pauses (after auto-playing). And the expected behavior is: "the video pauses immediately after auto-playing", right? Without the web inspector things (the breakpoint and action), I did not see any issue after clicking the play/pause button. That's why I would like to clarify the reproducing steps. Thanks! (In reply to Peng Liu from comment #9) > OK. Regarding the reproducing steps, I guess you meant the time between the > following two event is a few seconds: > - The console outputs "pause blob: ****". > - The video pauses (after auto-playing). > > And the expected behavior is: "the video pauses immediately after > auto-playing", right? > > Without the web inspector things (the breakpoint and action), I did not see > any issue after clicking the play/pause button. That's why I would like to > clarify the reproducing steps. Thanks! Right. The timing of the pause is crucial to reproduce the bug. It might be very difficult to manually pause ASAP after the video starts to play. I thought you meant something different by the question, and this made me do a little testing. I've now noticed that with the breakpoint and action, the video view and controls become somewhat unresponsive to clicking when the bug occurs. You can expose the <video> element directly to clicking by adding a little CSS to your Safari style sheet: video ~ div { display:none !important; } That should hide all of the non-native video controls. Created attachment 449697 [details]
Patch
Comment on attachment 449697 [details] Patch View in context: https://bugs.webkit.org/attachment.cgi?id=449697&action=review > Source/WebKit/WebProcess/GPU/media/MediaPlayerPrivateRemote.cpp:-230 > - m_cachedState.paused = false; Looks like this change will lead to a test (media/track/track-cues-pause-on-exit.html) timeout. (In reply to Peng Liu from comment #12) > Comment on attachment 449697 [details] > Patch > > View in context: > https://bugs.webkit.org/attachment.cgi?id=449697&action=review > > > Source/WebKit/WebProcess/GPU/media/MediaPlayerPrivateRemote.cpp:-230 > > - m_cachedState.paused = false; > > Looks like this change will lead to a test > (media/track/track-cues-pause-on-exit.html) timeout. Filed Bug 235465 to address it. Created attachment 449716 [details]
Remove some changes to address a test failure
Committed r288413 (246304@main): <https://commits.webkit.org/246304@main> All reviewed patches have been landed. Closing bug and clearing flags on attachment 449716 [details]. In my testing, this bug appears to be fixed in Safari Technology Preview 140. Thanks! This fix shipped with Safari 15.5 (all platforms). (In reply to Brent Fulgham from comment #17) > This fix shipped with Safari 15.5 (all platforms). Confirmed. |