question-mark
Stuck on an issue?

Lightrun Answers was designed to reduce the constant googling that comes with debugging 3rd party libraries. It collects links to all the places you might be looking at while hunting down a tough bug.

And, if you’re still stuck at the end, we’re happy to hop on a call to see how we can help out.

Do not autoplay audio dweets

See original GitHub issue

We can detect an audio dweet if:

  • It has been tagged #audio
  • It contains code Audio or SpeechSynthesis or …
  • (It looks like it has a compressor, and the uncompressed code contains the above) But just the hashtag would get us 99% of the way

Behaviour: An audio dweet should just start off paused. There will be a ‘Play’ button the user can click if they want to start the dweet running.

Optional extra:

  • A ‘Pause’ or ‘Stop’ button that can stop all started audio. One way to achieve this might be to override the Audio and SpeechSynthesis` constructors with our own functions that call the original functions, but also keep a copy of the constructed object in a global array, so that we can stop them when the button is pressed. This might also be an advantage when someone is editing an audio dweet. When they change the dweet, our reset function can stop all the existing audio output, to provide a clean slate for the new version.

Issue Analytics

  • State:open
  • Created 5 years ago
  • Comments:10 (6 by maintainers)

github_iconTop GitHub Comments

1reaction
lionleafcommented, Sep 8, 2018

Using #audio would definitely get us pretty close, as if the author forgets to add it somebody else could. However, I worry we could then get people tagging random dweets as “#audio” as to disable autoplay.

Regex matching on the dweet would also get us pretty far, it will catch most normal audio dweets, but if somebody wants to they could always evade it.

We could override the Audio and SpeechSynthesis constructors with something that automatically mutes the sounds and presents an ‘unmute’ button somehow?

0reactions
KilledByAPixelcommented, May 28, 2019

Domp handles starting and stopping audio when clicked on as well as some other handy stuff.

Would it be possible to have Dwitter create an default audio context the same way it creates a canvas context? It’s basically the same thing as the canvas but for audio. This could give dwitter more control while also allowing more space for audio code.

Read more comments on GitHub >

github_iconTop Results From Across the Web

How to Turn Off Autoplay Videos - PCMag
Click Accessibility, display, and language > Data usage > Autoplay > Never, which will prevent videos and GIFs from automatically playing as you...
Read more >
Autoplay guide for media and Web Audio APIs
Automatically starting the playback of audio (or videos with audio tracks) immediately upon page load can be an unwelcome surprise to users.
Read more >
How to Stop Autoplay Video in Chrome | OSXDaily
The good news is that with a little secret settings adjustment you can easily disable autoplay video and autoplay audio on Chrome for...
Read more >
Audio or video element avoids automatically playing ... - W3C
This rule applies to any audio or video element for which all the following are true: autoplay: the element has an autoplay attribute...
Read more >
Offer option to disable audio autoplay - Stack Overflow
From the MDN. autoplay: A Boolean attribute; if specified (even if the value is "false"!), the audio will automatically begin playback as ...
Read more >

github_iconTop Related Medium Post

No results found

github_iconTop Related StackOverflow Question

No results found

github_iconTroubleshoot Live Code

Lightrun enables developers to add logs, metrics and snapshots to live code - no restarts or redeploys required.
Start Free

github_iconTop Related Reddit Thread

No results found

github_iconTop Related Hackernoon Post

No results found

github_iconTop Related Tweet

No results found

github_iconTop Related Dev.to Post

No results found

github_iconTop Related Hashnode Post

No results found