Fenix: [Bug] Background tabs stop playing media after some time

[kawaiiDango]

Steps to reproduce

1. Open a page playing media. I tried https://www.seraph.jp.net/blinddark
2. Open some sites (I tried Google searches) in 2-3 more tabs.

3a. The background tab playing media gets unloaded and the audio stops after about 40 secs. (When you select the tab with the media, the page reloads from scratch)
or
3b. Make sure that the tab playing media isn't the currently selected tab. Press back so that the app goes into the background. (3a) happens.

Expected behavior

Background tabs playing audio/video should not unload, until the playback is complete, just like Firefox desktop.

Actual behavior

Device information

• Android device: OnePlus 6, Android 10
• Fenix version: Nightly 200402 18:00 (Build #20931806)
  38.0.20200402130113, ea47f9c33

[Mentis]

Might be related to https://github.com/mozilla-mobile/fenix/issues/9039

[buttercookie42]

just like Firefox desktop.

... or Fennec (tabs playing audio were specifically protected from being unloaded).

[miketaylr]

As reported in https://github.com/webcompat/web-bugs/issues/48003, I can reproduce this same issue when switching tabs, or backgrounding the app. Audio stops around 20 or 30 seconds later.

[kawaiiDango]

I also noticed that background tabs get unloaded even when there's unsaved form data. I was writing an email, searched and copied stuff from another site and when I returned, everything was gone.

This is actual data loss and should be fixed.

[softvision-miralobontiu]

I reproduced this again today, on the latest Nightly build from 7/9 with Google Pixel (Android 10).
I had rockfm.ro opened in a tab, left Fenix in the background. After a while, 10-15 minutes, the media stopped. I had to refresh the tab and press play again.

[aroskuski]

I can reproduce this behavior with YouTube if I load the Video Background Play Fix extension via web-ext. The tab doesn't necessarily unload, but it does appear to stop whenever the video needs to buffer until I switch the tab to the foreground again.

[buttercookie42]

I wonder whether background tabs are marked as inactive (i.e. JS timeouts suspended amongst other things) even when they're playing back media? That would seem a conceivable explanation for pages loading the media using their own custom logic, like e.g. Youtube.

[aroskuski]

@buttercookie42 That definitely seems plausible. I just tried the player at http://audiocogs.org/codecs/flac/ (I think the other codecs on that site behave the same way if you don't have any FLAC files), which implements the audio playback entirely in JavaScript, and that stops immediately upon the tab losing focus, instead of continuing for a bit and then stopping. I'm not sure if there are any relevant technical differences between what that site is doing and normal video/audio tags, but it definitely seems to point to JavaScript not being run for background tabs playing media being at least part of the problem.

For comparison, the audiocogs players do keep playing in background tabs in Fennec.

[robsmith11]

I experienced this as well when using YouTube in desktop mode.

[buttercookie42]

It seems that "Video Background Play Fix" has become officially installable (at least on Nightly), which is nice, but this means that everybody who attempts to install that add-on will then run into this bug and potentially presume the add-on is broken when in fact Firefox is to blame.

[dezraj]

I'm also experiencing this bug. Any workaround you guys have been using whilst this isn't fixed? I usually play rain sounds on YouTube to help me sleep.

[robsmith11]

Did you try flipping media.suspend-bkgnd-video.enabled in about:config? It worked for me.

[buttercookie42]

Are you certain about that pref? As far as I can remember, that is only responsible for shutting down video decoding, but not (audio) playback, and Fennec already did that, too. Someone else reported success with flipping dom.suspend_inactive.enabled, which does indeed seem a more likely culprit (and was only added comparatively recently).

[robsmith11]

Ah you're probably right. I had flipped both of those flags.

[oidualc]

Might be related to #9039

I think it isn't, I'm not able to reproduce #9039 but still experiencing this bug.

[klint]

dom.suspend_inactive.enabled did the trick for me. Yet I don't know the side effects of flipping it.

[yoasif]

Confirmed that flipping dom.suspend_inactive.enabled works.

[Hubfront]

It works but seems to keep all tabs active regarding site updates. I am not sure if this not leads to increased power consumption too.

[YSavanier]

It also affect youtube music launched in desktop mode wich allowed unlimited background playback on firefox v68.
I uninstalled fenix and downgraded it with a v68 apk until this got fixed.
Seriously folks, that update is such a mess and come in at the worst time while the recent events at moz focused all tech medias lookinglass toward all the lighest trouble they could talk about to prophetize the end of Firefox as a Chrome alternative. So sad...

[andreicristianpetcu]

the workaround in https://github.com/mozilla-mobile/fenix/issues/9691#issuecomment-691635756 works

Nightly is much better than an old version. This might hit beta soon.

[andreicristianpetcu]

@csadilek I don't think we should ship Video Background Play fix to stable since it's broken without the about:config workaround which cannot be applied to stable. Please remove it from the collection that will be shipped in September. https://addons.mozilla.org/en-US/android/collections/4757633/83a9cccfe6e24a34bd7b155ff9ee32/

We should still have this extension in Nightly and Beta where there is a workaround.

https://github.com/mozilla-mobile/fenix/commit/601e847094d2d849a85d4fb2dfb40b34dc1eef5f

[agi]

The fix landed very recently, could y'all test again? It should work on the latest nightly and latest beta now (it does for me).

[lpd-au]

The fix landed very recently, could y'all test again? It should work on the latest nightly now (it does for me).

@agi could you please point me towards the commit that fixes the bug? Thanks!

[agi]

@lpd-au https://bugzilla.mozilla.org/show_bug.cgi?id=1662805

[klint]

So far so good for me! 😊 Thanks

[Hubfront]

I extra reinstalled nightly from play store but background youtube video again stops working after several minutes for me. Maybe i got different build?

Mine is:

Nightly 200924 06:03 (Build #2015765747)
AC: 61.0.20200923130632, f4eea2a92
GV: 83.0a1-20200922094538
AS: 63.0.0

Thursday 9/24 @ 6:10 AM

[aroskuski]

For what it's worth, it did seem to work for me on both the latest beta and nightly. That said, I did have the tab that was playing audio get unloaded several times while attempting to test it, despite only really having one other tab open, which obviously stopped the audio from playing. I think Fenix's general aggressiveness with unloading tabs compared to Fennec might be a separate, more general issue, though.

The two scenarios I tested were:

• YouTube with Video Background Play Fix installed
• Playing a .flac file on this page: http://audiocogs.org/codecs/flac/

Versions tested:
Nightly 200924 06:03 (Build #2015765747)
AC: 61.0.20200923130632, f4eea2a92
GV: 83.0a1-20200922094538
AS: 63.0.0

82.0.0-beta.1 (Build #2015765523)
AC: 60.0.1, e3661f62f
GV: 82.0-20200922183749
AS: 63.0.0

[andreicristianpetcu]

Works great on both beta and nightly with the workaround disabled. Thank you.

[agi]

@aroskuski yeah that's a separate issue I'm looking into. What device did you test it on?

[aroskuski]

@agi It was a Pixel 3

[meetthemeat]

@agi
Unfortunately an audio stream stopped also in my case after approx. 15min. When the browser was running in the background while using another app.

Nightly 200925 06:01 (Build #2015765939)
AC: 61.0.20200923190103, 50960c843
GV: 83.0a1-20200922094538
AS: 63.0.0

Tested on:

• OPO2
• Lineage OS16

[Amejia481]

QA team please we want to verify if this issue is still reproducible in nightly. Thanks!

[klint]

Have you excluded fenix from any battery saving strategy? It might be Android killing fenix..

[softvision-miralobontiu]

Verified as fixed on the latest Nightly build from 10/7 using Google Pixel (Android 10), and Samsung Galaxy Tab S6 (Android 10).
I've left rockfm.ro, and youtube playing in the background for more than 3 hours.
I'll remove the label and close the issue.

PS: On Beta 82.0.0-beta.4, and on RC 81.1.3 I was still able to reproduce the issue, the media stopped playing after 5-10 minutes.

[dezraj]

Any idea of when should this fix come with an update from Play Store?

[Amejia481]

@st3fan the patch for this issue will be uplifted?

[st3fan]

@Amejia481 If I understand correctly, this only needed https://bugzilla.mozilla.org/show_bug.cgi?id=1662805 which was uplifted to GV 82 16 days ago. We shipped 82.0.0-beta.4 release today, which should have GV 82 from October 2nd, so this fix must be in there.

@agi would you mind giving Fenix Beta a try to verify this?

[Amejia481]

Thanks for the clarification :)

[buttercookie42]

Playlists on Youtube still don't work though – whatever grace period might or might not exist after playback of one track has stopped isn't long enough to actually load the next track and start playback again.

[st3fan]

Background playing of a playlist is probably a different problem. Regarding YouTube: they have been pushing people very hard to their premium offering to support background playing. I think we should investigate how this works, but a playlist not progressing in the background could definitely be YouTube simply not allowing that.

[buttercookie42]

Theoretically yes, but in practice playlists are working perfectly fine with the Fennec codebase, and like I've already written in #15753, fiddling around with dom.media.silence_duration_for_audibility also improves the situation (but seems to expose a different bug instead, so background playback still doesn't work properly).
Therefore, I'd strongly suspect that if someone with a premium account were to try this out, they'd still run into the same issue when using the rewritten Firefox…

[agi]

@buttercookie42 I don't think we have a grace period after playback ends. We immediately set the tab as inactive which causes all timers to fire at a reduced rate etc. I suspect that's breaking youtube playlists.

[buttercookie42]

I guess you're right, although for the particular playlist I've tested with the default value of two seconds for dom.media.silence_duration_for_audibility is definitively a little bit too short as well.