Page MenuHomePhabricator

Sometimes audio plays back twice when opening the player
Closed, ResolvedPublicBUG REPORT

Description

Take an audio sample like on https://www.mediawiki.org/wiki/Extension:TimedMediaHandler/VideoJS_Player

Every once in a while, when you click the audio player to open the dialog, you get the audio sample playing TWICE. This seems related to the play/pause logic we do on the original element to ensure autoplay interaction permissions.

  • the first play is registered (native playback of mp3 or vorbis source)
  • the pause is also executed
  • but it seems the pause is sometimes not actually pausing inside Safari

I did some investigation and the pause is inside the promise now (to fix the error with the abort we were sometimes seeing when pausing during the play phase). It seems to me that this is a bug in Safari, and when I do setTimeout around the pause action, it works much more reliably, because it gets put on the next execution cycle.

Be careful with debugging, long pauses invalidate the play action, console logging is more accurate for analysing this problem. For videos it seems we never even get around to playing at all, as the load phase simply takes too long and/or because we don't have native playback support for these elements.

Event Timeline

TheDJ triaged this task as Medium priority.Feb 14 2022, 11:02 PM
TheDJ changed the subtype of this task from "Task" to "Bug Report".

@brion so this one specifically. We do autoplay busting with a play/pause action here: https://gerrit.wikimedia.org/r/plugins/gitiles/mediawiki/extensions/TimedMediaHandler/+/refs/heads/master/resources/ext.tmh.player.element.js#254

I think how this works is that if the play action is not within a certain timeframe (because we are slowy loading JS) the play action is 'too late' and the play action fails ?

Now this has a comment that it was really for Safari... But i'm not entirely sure if that is actually true and if Google does not also cancel the userinteraction after some time and won't play the file. We should maybe double check this ? If it is safari only, we could move it into a Safari only block, so we at least don't bother other browsers with this.

And the setTimeout( 0) as a workaround does seem to work to me, but if there is anything we can do to just get rid of this.. even better i think right ?

Change 770590 had a related patch set uploaded (by TheDJ; author: TheDJ):

[mediawiki/extensions/TimedMediaHandler@master] Defer pause of autoplay busting

https://gerrit.wikimedia.org/r/770590

Note that for audiocontext we can/should check for suspended state? https://developer.mozilla.org/en-US/docs/Web/API/Web_Audio_API/Best_practices

I'm starting to suspect we can/should simply remove this autoplay busting... I don't really see the point of it any longer.

Change 770590 merged by jenkins-bot:

[mediawiki/extensions/TimedMediaHandler@master] Defer pause of autoplay busting

https://gerrit.wikimedia.org/r/770590

TheDJ claimed this task.

This hasn't happened anymore