This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.
Specification: http://www.whatwg.org/specs/web-apps/current-work/multipage/the-video-element.html Multipage: http://www.whatwg.org/C#playing-the-media-resource Complete: http://www.whatwg.org/c#playing-the-media-resource Referrer: http://www.whatwg.org/specs/web-apps/current-work/multipage/ Comment: Does seeking to the end trigger the loop/ended/pause steps? Posted from: 58.187.26.12 User agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_9_2) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/33.0.1750.117 Safari/537.36 OPR/20.0.1387.59 (Edition Next)
I was going to write some test cases for this, but don't know if the spec says what it should right now. If the media element is paused and one sets currentTime to duration, does that trigger "When the current playback position reaches the end of the media resource when the direction of playback is forwards"? AFAICT it does. I'm not certain this edge case (involving loop) matter but want to make sure it's intentional and not an oversight.
Spec seems unambiguous here, but I've added text to make it clear that it's not an oversight. Quick testing shows Safari and Chrome on Mac do this correctly today. Let me know if there's anything else that needs doing here.
Checked in as WHATWG revision r8551. Check-in comment: Try to clarify looping rules http://html5.org/tools/web-apps-tracker?from=8550&to=8551
There is actually one more thing that I'm unsure of now that I tried to write the test again. It's not really clear when the "reaches the end of the media resource when the direction of playback is forwards" step can run. If you seek to duration without loop, you should expect the events "seeking, timeupdate, seeked". With loop, there will be a second seek with these same events, but when? Is it when the seeking algorithm awaits a stable state, or does it wait until the first seek is finished? In other words, is the event order "seeking, timeupdate, seeked, seeking, timeupdate, seeked", just "seeking, timeupdate, seeked" or perhaps "seeking, timeupdate, seeking, timeupdate, seeked"?
Wouldn't it just happen synchronously in seek's step 11? Step 1 aborts the previous instance, so it would presumably go seeking, seeking, timeupdate, seeked. I can add a note in step 11 that points out that this triggers the other condition synchronously, if you like.
Now that you point it out it's quite clear, since "current playback position" is used in both definitions. A note at that point wouldn't hurt though, since I doubt this is the event order in existing implementations.
Checked in as WHATWG revision r8575. Check-in comment: Clarify the interaction of looping and seeking. http://html5.org/tools/web-apps-tracker?from=8574&to=8575