Issue 543853 in chromium: canplaythrough event firing hundreds of times per second

[chro...@googlecode.com]

Status: Unconfirmed
Owner: ----
Labels: Cr-Platform-Extensions Pri-2 Via-Wizard Type-Bug OS-Mac

New issue 543853 by dshekht...@hubspot.com: canplaythrough event firing
hundreds of times per second
https://code.google.com/p/chromium/issues/detail?id=543853

UserAgent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_10_4)
AppleWebKit/537.36 (KHTML, like Gecko) Chrome/46.0.2490.71 Safari/537.36

Steps to reproduce the problem:
This is difficult for you to reproduce because it involves authenticating
into a system that you cannot auth to.

What is the expected behavior?
There is some code in this extension (I wrote it) like:

var ring = new Audio('/audio/ring1.ogg');

chrome.storage.sync.get(function(settings) {
ring.src = '/audio/'+settings.ringType+'.ogg';
ring.volume = settings.volume;
ring.load();
ring.oncanplaythrough = function() {
console.log('Playing ring '+ new Date());
ring.currentTime = 0;
ring.play();
};
});

According to the 'oncanplaythrough' event listener, the function should be
fired when the audio is loaded enough to play, and then the "ring" should
play.

What went wrong?
As of Chrome 46 (I think), the 'canplaythrough' event fires hundreds of
times a second leading to some very weird behavior.

I tested this on a computer with Chrome 45 and it works as expected, which
leads me to believe that something in Chrome 46 is firing that event too
much.

WebStore page:
https://chrome.google.com/webstore/detail/zorse-notifyer/mbcfeikpllghlnbehcikbbbnekjpkhol

Did this work before? Yes Before Chrome 46

Chrome version: 46.0.2490.71 Channel: stable
OS Version: OS X 10.10.4
Flash Version: Shockwave Flash 19.0 r0

I haven't changed any code and believe the issue is a problem with the
canplaythrough event for audio elements.

Attachments:
Screen Shot 2015-10-15 at 6.03.28 PM.png 699 KB

--
You received this message because this project is configured to send all
issue notifications to this address.
You may adjust your notification preferences at:
https://code.google.com/hosting/settings

[chro...@googlecode.com]

Updates:
Labels: TE-NeedsFurtherTriage

Comment #2 on issue 543853 by ranjit...@chromium.org: canplaythrough event

firing hundreds of times per second
https://code.google.com/p/chromium/issues/detail?id=543853

(No comment was entered for this change.)

[chro...@googlecode.com]

Comment #3 on issue 543853 by Slava.pa...@gmail.com: canplaythrough event

firing hundreds of times per second
https://code.google.com/p/chromium/issues/detail?id=543853

I confirm this behavior of Chrome 46 and I think that prior to some
sub-version of version 46, event canplaythrough was not fired once the
sound started playing. Now it continuous to fire even as the sound plays. I
don;t kn ow which is more logical, and whether there is a standard for this
behavior in the WC# specs. The solution for now is to use
removeEvenListener as soon as the sound starts playing (or whatever other
action your codes takes when canplaythrough fires the first time).

[chro...@googlecode.com]

Comment #4 on issue 543853 by dshekht...@hubspot.com: canplaythrough event

firing hundreds of times per second
https://code.google.com/p/chromium/issues/detail?id=543853

Thanks for taking a look, Slava. I'll try your workaround and let you know
how it goes.

[chro...@googlecode.com]

Comment #5 on issue 543853 by matt.hac...@gmail.com: canplaythrough event

firing hundreds of times per second
https://code.google.com/p/chromium/issues/detail?id=543853

I ran into this same issue a while ago, but didn't look into it much as I
thought it was a dupe of
https://code.google.com/p/chromium/issues/detail?id=537725

As the canary build didn't resolve, I've poked around more. The main issue
seems to be from setting currentTime while inside the context of the
canplaythrough event. Even when async'd with a timer, the event will be
refired once currentTime is changed. This doesn't happen if currentTime is
altered anywhere else.

I've got two tests set up repro'ing the issue and showing it working
correctly:
Broken: http://codepen.io/anon/pen/PPBgvQ
Working: http://codepen.io/anon/pen/epjowO

This has been tested against canary as it uses the same broken MP3 from the
bug above, but the issue is identical on Chrome 46 (all platforms) with any
correctly playing MP3.