This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.
This may be a bug in browser implementations of the spec, but because all browsers make the same mistake I believe it may be a spec bug that needs some clarifying text. When a media resource that has a @controls attribute has played through to the end and has thrown an "ended" event, browsers put the state of the @controls display to a "pause" button. As a user presses the "play" button again, the video/audio starts playing back from the beginning, but the "play" event is not raised again. I believe the reason for this is that the spec says to throw the "play" event when "paused is newly false", see http://www.whatwg.org/specs/web-apps/current-work/multipage/video.html#event-media-play . I don't believe this is sufficient, because upon "ended" the state of the media resource is not set to "paused". Also, the reason is that description of the steps to run after the "play()" function is called includes the following: "2. If the playback has ended and the direction of playback is forwards, seek to the earliest possible position of the media resource. Note: This will cause the user agent to queue a task to fire a simple event named timeupdate at the media element." I suggest also adding to this not to throw the "play" event.
(In reply to comment #0) > "2. If the playback has ended and the direction of playback is forwards, seek > to the earliest possible position of the media resource. > Note: This will cause the user agent to queue a task to fire a simple event > named timeupdate at the media element." > > I suggest also adding to this not to throw the "play" event. Gosh, what difference a simple character makes! I meant: adding to this NOTE to also throw the "play" event.
I believe the browsers match the spec. When the video is ended, you're still in the playing state, so if you seek back somewhere (e.g. to the beginning), you don't fire 'play' since the playing state hasn't changed. What's the problem with not firing 'play' in this situation? Do you actually really want the state to become paused when the video has ended? (If you seek back using the seekbar after the video has ended, do you want the video to play or not?)
I was speaking from a user and web developer viewpoint. For the user what happens is that the video plays through and visually goes into a paused state. Then the user hits the play button again, but the onplay event doesn't fire for the web developer. That to me seems a disconnect, since both the user and the web developer perceive a change in play state, but the browser doesn't recognize that. It seems logical that when the user hits the play button, the onplay event should fire. Your suggestion of setting the state upon ended to paused may be another way of fixing the problem. I'd be happy with either solution as long as it has the effect that when a user hits the play button an onplay event is fired.
You don't get a play event when the user hits play while the video is in the middle and playing, or while the video is in the middle and buffering. All that play() does when you're ended is seek to the start. You do get events for that (several of them). (In reply to comment #2) > > IIf you seek back using the seekbar after the video has ended, do you > want the video to play or not? That's a good question. What's the answer?
EDITOR'S RESPONSE: This is an Editor's Response to your comment. If you are satisfied with this response, please change the state of this bug to CLOSED. If you have additional information and would like the editor to reconsider, please reopen this bug. If you would like to escalate the issue to the full HTML Working Group, please add the TrackerRequest keyword to this bug, and suggest title and text for the tracker issue; or you may create a tracker issue yourself, if you are able to do so. For more details, see this document: http://dev.w3.org/html5/decision-policy/decision-policy.html Status: Did Not Understand Request Change Description: no spec change Rationale: see comment 4