WebKit Bugzilla
New
Browse
Log In
×
Sign in with GitHub
or
Remember my login
Create Account
·
Forgot Password
Forgotten password account recovery
RESOLVED FIXED
Bug 60972
Audio element doesn't emit the 'playing' event every time it starts playing, after it has finished playing
https://bugs.webkit.org/show_bug.cgi?id=60972
Summary
Audio element doesn't emit the 'playing' event every time it starts playing, ...
Gustavo Noronha (kov)
Reported
2011-05-17 10:38:20 PDT
Created
attachment 93794
[details]
test case This behaviour seems to be a bit flaky. In a page with a simple audio element with an onplaying attribute that shows an alert I sometimes get the alert every time I click play, other times I only get it the first time. I wrote a simple layout test that reproduces the problem here on WebKitGTK+. A friend has also reproduced it in Chromium so I believe this is a cross-platform issue.
Attachments
test case
(622 bytes, text/html)
2011-05-17 10:38 PDT
,
Gustavo Noronha (kov)
no flags
Details
patch
(4.28 KB, patch)
2011-09-02 08:18 PDT
,
Arko Saha
eric.carlson
: review-
Details
Formatted Diff
Diff
updated patch
(4.63 KB, patch)
2011-09-23 06:59 PDT
,
Arun Patole
webkit.review.bot
: commit-queue-
Details
Formatted Diff
Diff
updated patch
(6.92 KB, patch)
2011-09-26 00:16 PDT
,
Arun Patole
pnormand
: review-
Details
Formatted Diff
Diff
updated patch
(6.87 KB, patch)
2011-09-26 23:49 PDT
,
Arun Patole
pnormand
: review-
Details
Formatted Diff
Diff
updated patch
(6.88 KB, patch)
2011-09-27 00:21 PDT
,
Arun Patole
no flags
Details
Formatted Diff
Diff
Show Obsolete
(3)
View All
Add attachment
proposed patch, testcase, etc.
Gustavo Noronha (kov)
Comment 1
2011-05-17 10:41:18 PDT
This is what I get running that layout test: RUN(mediaElement.src = findMediaFile('audio', 'content/silence')) RUN(mediaElement.play()) EVENT(playing) EVENT(ended) RUN(mediaElement.play()) EVENT(ended) END OF TEST I expected to see another EVENT(playing) between the second RUN(...) and EVENT(ended) there.
Arko Saha
Comment 2
2011-09-02 08:18:46 PDT
Created
attachment 106138
[details]
patch Emit 'playing' event every time starts playing, after playback ended.
Eric Carlson
Comment 3
2011-09-02 08:49:44 PDT
Comment on
attachment 106138
[details]
patch This is not correct, the 'playing' event should only fire when the element goes from the paused state to the playing state. Read the spec:
http://www.whatwg.org/specs/web-apps/current-work/multipage/the-video-element.html#dom-media-play
Arko Saha
Comment 4
2011-09-13 03:09:10 PDT
> This is not correct, the 'playing' event should only fire when the element goes from the paused state to the playing state. Read the spec:
http://www.whatwg.org/specs/web-apps/current-work/multipage/the-video-element.html#dom-media-play
Current spec does not say it but I think, the Paused attribute should also be set to true when : - The current playback position is the end of the media resource, and the media element does not have a loop attribute specified. Please let me know your suggestion.
Eric Carlson
Comment 5
2011-09-13 10:47:03 PDT
(In reply to
comment #4
)
> > This is not correct, the 'playing' event should only fire when the element goes from the paused state to the playing state. Read the spec:
http://www.whatwg.org/specs/web-apps/current-work/multipage/the-video-element.html#dom-media-play
> > Current spec does not say it but I think, the Paused attribute should also be set to true when : > - The current playback position is the end of the media resource, and the media element does not have a loop attribute specified. > > Please let me know your suggestion. >
If you think the spec is incorrect, please file a bug against the spec. You can do this directly from inline issues box in the spec itself, or from
http://www.w3.org/Bugs/Public/enter_bug.cgi
if you have a W3C account.
Arun Patole
Comment 6
2011-09-23 06:58:48 PDT
(In reply to
comment #5
)
> If you think the spec is incorrect, please file a bug against the spec. You can do this directly from inline issues box in the spec itself, or from
http://www.w3.org/Bugs/Public/enter_bug.cgi
if you have a W3C account.
The spec is changed now, as per the latest spec:
http://www.whatwg.org/specs/web-apps/current-work/#ended-playback
"Queue a task that, if the media element does not have a current media controller, and the media element has still ended playback, and the direction of playback is still forwards, and paused is false, changes paused to true and fires a simple event named pause at the media element."
Arun Patole
Comment 7
2011-09-23 06:59:47 PDT
Created
attachment 108471
[details]
updated patch
WebKit Review Bot
Comment 8
2011-09-23 09:29:22 PDT
Comment on
attachment 108471
[details]
updated patch
Attachment 108471
[details]
did not pass chromium-ews (chromium-xvfb): Output:
http://queues.webkit.org/results/9822095
New failing tests: media/event-attributes.html svg/custom/svg-fonts-word-spacing.html media/video-loop.html
Arun Patole
Comment 9
2011-09-26 00:16:56 PDT
Created
attachment 108631
[details]
updated patch
Philippe Normand
Comment 10
2011-09-26 08:29:35 PDT
Comment on
attachment 108631
[details]
updated patch View in context:
https://bugs.webkit.org/attachment.cgi?id=108631&action=review
Looks good in general, just some nits and a speed improvement suggestion for the test.
> Source/WebCore/ChangeLog:8 > + As per the latest spec, paused attribute should be set to true and fire 'pause' event on end of media playback.
"latest" is vague, if you can't mention the spec revision that introduced this change. For the rest of the sentence here's my take :) the paused attribute should be set to true and the media element should emit a 'paused' at the end of playback.
> Source/WebCore/ChangeLog:13 > + (WebCore::HTMLMediaElement::mediaPlayerTimeChanged): set m_paused to true and schedule 'pause' event if end of playback.
s/if end of playback/when playback ended/
> LayoutTests/ChangeLog:8 > + As per the latest spec, paused attribute should be set to true and fire 'pause' event on end of media playback.
No need to copy/paste from the other ChangeLog entry.
> LayoutTests/ChangeLog:14 > + * media/event-attributes-expected.txt: Modified as the 'pause' event is fired on end of media playback. > + * media/event-attributes.html: Modified as the 'pause' event is fired on end of media playback. > + * media/media-element-play-after-eos-expected.txt: Added. > + * media/media-element-play-after-eos.html: Added. > + * media/video-loop-expected.txt: Modified as the 'pause' event is fired on end of media playback.
Instead of copy/pasting 3 times the same sentence let's just put it as a general note above.
> LayoutTests/media/media-element-play-after-eos.html:12 > + run("mediaElement.src = findMediaFile('audio', 'content/silence')");
We usually don't log this, no need for run()
> LayoutTests/media/media-element-play-after-eos.html:32 > + run("mediaElement.play()"); > + repeated = true;
So the test plays the silence file twice? It's about 1.1 seconds so this test runs in more than 2 seconds. Maybe it'd be worth to perform a seek near the end of the media when the "playing" event is received.
Arun Patole
Comment 11
2011-09-26 23:48:15 PDT
(In reply to
comment #10
) Thanks for the review!
> > "latest" is vague, if you can't mention the spec revision that introduced this change. > For the rest of the sentence here's my take :) > the paused attribute should be set to true and the media element should emit a 'paused' at the end of playback.
Done! Added revision no. and change set url.
> s/if end of playback/when playback ended/
Done!
> No need to copy/paste from the other ChangeLog entry. > Instead of copy/pasting 3 times the same sentence let's just put it as a general note above.
Ok, modified accordingly.
> We usually don't log this, no need for run() >
Done!
> So the test plays the silence file twice? It's about 1.1 seconds so this test runs in more than 2 seconds. Maybe it'd be worth to perform a seek near the end of the media when the "playing" event is received.
Modified test to seek by 1 sec on 'playing' event.
Arun Patole
Comment 12
2011-09-26 23:49:06 PDT
Created
attachment 108793
[details]
updated patch
Philippe Normand
Comment 13
2011-09-27 00:01:52 PDT
Comment on
attachment 108793
[details]
updated patch View in context:
https://bugs.webkit.org/attachment.cgi?id=108793&action=review
Much better, thanks! Just a last small issue to fix.
> LayoutTests/media/media-element-play-after-eos.html:21 > + mediaElement.currentTime = 1;
Usually to seek near the end we use duration - 0.2 or something like that. It's more explicit and more reliable if the test uses another media file in the future.
Arun Patole
Comment 14
2011-09-27 00:21:14 PDT
(In reply to
comment #13
)
> Usually to seek near the end we use duration - 0.2 or something like that. It's more explicit and more reliable if the test uses another media file in the future.
Yes, you are right. I have modified the test.
Arun Patole
Comment 15
2011-09-27 00:21:55 PDT
Created
attachment 108795
[details]
updated patch
WebKit Review Bot
Comment 16
2011-09-27 01:32:27 PDT
Comment on
attachment 108795
[details]
updated patch Clearing flags on attachment: 108795 Committed
r96082
: <
http://trac.webkit.org/changeset/96082
>
WebKit Review Bot
Comment 17
2011-09-27 01:32:33 PDT
All reviewed patches have been landed. Closing bug.
Ryosuke Niwa
Comment 18
2011-09-28 17:51:55 PDT
The test added by this test has been failing on Snow Leopard:
http://build.webkit.org/results/SnowLeopard%20Intel%20Release%20(Tests)/r96082%20(33415)/media/video-does-not-loop-pretty-diff.html
Ryosuke Niwa
Comment 19
2011-09-28 17:54:18 PDT
Not that the test added by this test but the one that's rebaselined: LayoutTests/media/video-loop.html
Arun Patole
Comment 20
2011-09-29 00:34:25 PDT
(In reply to
comment #19
)
> Not that the test added by this test but the one that's rebaselined: LayoutTests/media/video-loop.html
As discussed, media/video-does-not-loop.html is failing and not the rebaselined: LayoutTests/media/video-loop.html I have opened bug for this:
https://bugs.webkit.org/show_bug.cgi?id=69067
Eric Carlson
Comment 21
2011-10-10 15:25:02 PDT
***
Bug 42037
has been marked as a duplicate of this bug. ***
Eric Carlson
Comment 22
2011-10-10 15:34:23 PDT
***
Bug 45203
has been marked as a duplicate of this bug. ***
Note
You need to
log in
before you can comment on or make changes to this bug.
Top of Page
Format For Printing
XML
Clone This Bug