918332 - We should hold wake locks more aggressively when HTMLAudioElement are being manipulated by script

Status: REOPENED

(Core :: Audio/Video: Playback, defect)

Description

[Reuben Morais [:reuben]]

Bandcamp has enabled their HTML5 player by default. They use a single <audio> element and swap the source using JS to play the next song. The problem is, if you leave an album page playing for long enough that OS X would go to sleep, it'll sleep as soon as a song is over and the source is being swapped with the next one in JS.

I don't know exactly how the keep-the-system-on machinery works, but maybe we should be more aggressive when audio elements are being manipulated by script to prevent this situation from happening.

Thoughts?

Comment 1

[Nils Ohlmeier [:drno]]

Mass closing do to inactivity.
Feel free to re-open if still needed.

Comment 2

[Reuben Morais [:reuben]]

I can still reproduce this on Nightly 72 on macOS.

STR:

1. Set sleep preference to a short duration (1 minute)
2. Open an album page and play a song that's longer than the time set above. Example link: https://protodome.bandcamp.com/album/chipfunk
3. Wait until the song ends

Results: Display goes to sleep, song keeps playing, then when it ends the next song doesn't play.

Expected results: Next song in the album plays after the current one is finished.

Comment 3

[Reuben Morais [:reuben]]

Soundcloud manages to avoid this problem somehow. I think it's using the WebAudio API instead of an <audio> element.