RESOLVED FIXED216017
<video> element prevents screen from sleeping even after playback finishes
https://bugs.webkit.org/show_bug.cgi?id=216017
Summary <video> element prevents screen from sleeping even after playback finishes
Chris Dumez
Reported 2020-08-31 16:20:56 PDT
<video> element prevents screen from sleeping even after playback finishes.
Attachments
Patch (5.25 KB, patch)
2020-08-31 16:33 PDT, Chris Dumez
no flags
Patch (2.26 KB, patch)
2020-08-31 16:42 PDT, Chris Dumez
no flags
Chris Dumez
Comment 1 2020-08-31 16:21:08 PDT
Chris Dumez
Comment 2 2020-08-31 16:33:25 PDT
Chris Dumez
Comment 3 2020-08-31 16:42:34 PDT
Darin Adler
Comment 4 2020-08-31 17:53:10 PDT
Comment on attachment 407636 [details] Patch View in context: https://bugs.webkit.org/attachment.cgi?id=407636&action=review > Source/WebCore/ChangeLog:14 > + To address the problem, we now call updateSleepDisabling() when This says updateSleepDisabling, which makes logical sense. > Source/WebCore/platform/graphics/avfoundation/objc/MediaPlayerPrivateAVFoundationObjC.mm:3171 > + rateChanged(); This says rateChanged, which makes less sense.
Chris Dumez
Comment 5 2020-08-31 19:07:17 PDT
(In reply to Darin Adler from comment #4) > Comment on attachment 407636 [details] > Patch > > View in context: > https://bugs.webkit.org/attachment.cgi?id=407636&action=review > > > Source/WebCore/ChangeLog:14 > > + To address the problem, we now call updateSleepDisabling() when > > This says updateSleepDisabling, which makes logical sense. > > > Source/WebCore/platform/graphics/avfoundation/objc/MediaPlayerPrivateAVFoundationObjC.mm:3171 > > + rateChanged(); > > This says rateChanged, which makes less sense. rateChanged() is what Jer recommended I call. This ends up calling HTMLMediaElement::mediaPlayerRateChanged() which calls updateSleepDisabling(). I initially introduced a new delegate just for this but Jer suggested I rely on the pre-existing rateChanged() instead.
Jer Noble
Comment 6 2020-09-01 09:43:02 PDT
lgtm. The KVO property which AVFoundation changes does double duty, representing whether the underlying player is playing or paused, but also whether this is due to a network stall or a direct user action. So the confusion is understandable. But sending a "rateChanged()" notification is definitely the correct thing here.
Darin Adler
Comment 7 2020-09-01 10:36:42 PDT
(In reply to Jer Noble from comment #6) > The KVO property which AVFoundation changes does double duty, representing > whether the underlying player is playing or paused, but also whether this is > due to a network stall or a direct user action. So the confusion is > understandable. But sending a "rateChanged()" notification is definitely > the correct thing here. WebKit doesn’t have to follow the AVFoundation naming. We could come up with a name other than "rate" for this if we like.
Chris Dumez
Comment 8 2020-09-01 12:27:08 PDT
(In reply to Darin Adler from comment #7) > (In reply to Jer Noble from comment #6) > > The KVO property which AVFoundation changes does double duty, representing > > whether the underlying player is playing or paused, but also whether this is > > due to a network stall or a direct user action. So the confusion is > > understandable. But sending a "rateChanged()" notification is definitely > > the correct thing here. > > WebKit doesn’t have to follow the AVFoundation naming. We could come up with > a name other than "rate" for this if we like. That was my original proposal, something like a new pausedStateChanged(). Jer still preferred we call the existing rateChanged() instead of introducing a new delegate so I will let him comment before landing.
Darin Adler
Comment 9 2020-09-01 13:08:13 PDT
We should land this change and debate the naming thing at our leisure separately.
Jer Noble
Comment 10 2020-09-01 13:11:33 PDT
(In reply to Chris Dumez from comment #8) > (In reply to Darin Adler from comment #7) > > (In reply to Jer Noble from comment #6) > > > The KVO property which AVFoundation changes does double duty, representing > > > whether the underlying player is playing or paused, but also whether this is > > > due to a network stall or a direct user action. So the confusion is > > > understandable. But sending a "rateChanged()" notification is definitely > > > the correct thing here. > > > > WebKit doesn’t have to follow the AVFoundation naming. We could come up with > > a name other than "rate" for this if we like. > > That was my original proposal, something like a new pausedStateChanged(). > Jer still preferred we call the existing rateChanged() instead of > introducing a new delegate so I will let him comment before landing. We can't change the behavior here without involving all the other ports; the callbacks are part of an abstraction layer used by all the MediaPlayer subclasses, and just adding new behavior in HTMLMediaElement runs the risk of breaking those ports. Adding a new message only for one engine just because the name of one of our underlying framework's properties is inconsistent is risky, both for us with other MediaPlayer subclasses who would have to start calling that new callback, and for other ports. I'd be fine with renaming "rateChanged()" to "pausedChanged()" or "playingChanged()". But that's refactoring work that can happen later, coordinated with other ports, in unison.
Jer Noble
Comment 11 2020-09-01 13:12:38 PDT
(In reply to Darin Adler from comment #9) > We should land this change and debate the naming thing at our leisure > separately. Totally.
EWS
Comment 12 2020-09-01 13:45:43 PDT
Committed r266410: <https://trac.webkit.org/changeset/266410> All reviewed patches have been landed. Closing bug and clearing flags on attachment 407636 [details].
Note You need to log in before you can comment on or make changes to this bug.