Bug 34047 - "endedPlayback" logic doesn't match spec
: "endedPlayback" logic doesn't match spec
Status: RESOLVED FIXED
Product: WebKit
Classification: Unclassified
Component: Media Elements
: 528+ (Nightly build)
: All All
: P2 Normal
Assigned To: Eric Carlson
: InRadar
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2010-01-23 23:05 PST by Eric Carlson
Modified: 2010-01-24 17:22 PST (History)
1 user (show)

See Also:


Attachments
Proposed patch (7.16 KB, patch)
2010-01-23 23:14 PST, Eric Carlson
simon.fraser: review+
Details | Formatted Diff | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Eric Carlson 2010-01-23 23:05:19 PST
Section 4.8.10.8, "Playing the media resource" says:

"A media element is said to have ended playback when the element's readyState attribute is HAVE_METADATA or greater, and either the current playback position is the end of the media resource and the direction of playback is forwards and the media element does not have a loop attribute specified, or the current playback position is the earliest possible position and the direction of playback is backwards."

but WebKit's HTMLMediaElement doesn't consider the direction of playback at all.
Comment 1 Eric Carlson 2010-01-23 23:07:00 PST
<rdar://problem/7573699>
Comment 2 Eric Carlson 2010-01-23 23:14:14 PST
Created attachment 47287 [details]
Proposed patch
Comment 3 Simon Fraser (smfr) 2010-01-24 08:35:14 PST
Comment on attachment 47287 [details]
Proposed patch

r=me but I wonder if the !loop() check should be done for backwards playback. Is reverse looping supposed to work?
Comment 4 Eric Carlson 2010-01-24 10:04:29 PST
Reverse looping isn't supported:

4.8.10.6
The loop attribute is a boolean attribute that, if specified, indicates that the media element is to seek back to the start of the media resource upon reaching the end.

and

4.8.10.8
When the current playback position reaches the earliest possible position of the media resource when the direction of playback is backwards, then the user agent must follow these steps:

1. Stop playback.

2. The user agent must queue a task to fire a simple event named timeupdate at the element.
Comment 5 Eric Carlson 2010-01-24 10:05:03 PST
Thanks for the review!
Comment 7 Eric Seidel 2010-01-24 14:22:44 PST
Looks like it broke Tiger in the same way:
http://build.webkit.org/results/Tiger%20Intel%20Release/r53782%20(8111)/media/audio-delete-while-slider-thumb-clicked-diffs.txt

(Just trying to clean up the bots after the commit-bot broke windows last night.)
Comment 8 Eric Carlson 2010-01-24 14:56:21 PST
http://trac.webkit.org/changeset/53786 should fix both, I made the test only log the first 'timeupdate' event.
Comment 9 Eric Seidel 2010-01-24 17:14:05 PST
Thanks!  Should this bug stay open for further work, or should we close it?