To help with complaints about websites using up lots of data while Fennec is in the background, maybe we should add a "Data saver" setting to restrict networking while Fennec is in the background. I'm not sure what would be required on the platform side to make this work, but on the UI side it could be a simple checkbox the user opts into. Barbara, what do you think?

Are we confident that this is only caused by websites and has nothing to do with how we deal with data usage in the background? Have we exhausted our investigation that it's something we can automatically prevent/handle on our end without giving the user a setting? If this is purely caused by the website (and also happens in other browsers), this could actually be a very good value prop / feature for our users, i.e. we care about their data. In addition to settings, it would be great to have contextual hint or warning appearing on the website if we encounter high data fetching (if possible). +antlam +snorp

We don't really have much data on what could be causing background data usage. It could be a long (never-ending, even) video, a runaway script, or something like that. I do feel it's somewhat unlikely that the front-end stuff could be causing this (except maybe sync). We just don't know. I think the idea of having some kind of networking restriction when we're backgrounded. It would probably be easy to just fail any connection attempt in that case, but I think there is a high likelihood of breaking stuff. Patrick what do you think about this?

I think what khuey is working on in terms of per-frame(?) event queues could be helpful here.. it would allow suspension of any queue (roughly tab) that was backgrounded.. that would suspend the js and any rendering.. if something were doing an already active network transfer that would technically immediately continue on the socket thread, but would shortly suspend itself when backpressure from the lack of a consumer kicked in. If we wanted to do something more direct I guess I would ask what processing (not just networking) fennec does at all when it is backgrounded that is desired, and if we understand that we can probably be a network filter. I definitely think we would want to focus on suspension and deferral rather than failures (after a while they will timeout and become failures anyhow).. otherwise brief bg events will create a lot of tabs in js error paths. It would be an interesting thing to explore, for sure.

A key part of this UX will have to be education. We already have a Settings section for "Data saver" so that might be a good part of the product to explore. I'd like to see some more research in this area before thinking more about this though.

(Note: Summary with proposed solutions at the bottom.) --- Speaking with experience as a UX designer: If this is a setting (or notification after the fact, like in bug 1024599), people will not notice it until it's too late (if at all, which is even more likely) and they're either out of data for the month[1] or are paying extra $€¥£ — with the worst case scenario of traveling with roaming[2] fees. [1] Which is what nearly happened to me in the _first day_ my billing cycle... [2] This bug is most likely why I also had much higher data usage during my vacation this past month compared to my girlfriend, and why my phone bill will quit a lot higher this month. I didn't figure it out until I got home and had WiFi issues with my neighbors this weekend, however, and my Firefox was using cell data in the background instead of WiFi for doing whatever it was that it was doing in the background for 300 megs overnight. (Current guess after reading bugzilla issues: a bad news article site with something about the US election, like CNN, probably.) Thankfully, I can afford an extra 40 euros — some people in the world cannot... and some roaming is even more expensive. Firefox on mobile needs to get better about data usage when using cell phone data by default or people will switch away when they get burned. If I weren't such a fan of Firefox, I would've switched too. In the meantime, I went into Android system preferences to disable all background data when on cell phone networks. It'll probably break things, but at least I won't have to pay extra per month for using Firefox. --- A better solution is to have data restrictions by default when on mobile (or on a restricted network, which is often WiFi tethering — see "Settings → Data Usage → Network Restrictions" on Android). For those with unlimited plans, they could flip a switch called "Restrict background data" to off within settings. As people don't often play around with settings in an app (nor should they), the background audio playing notification could be adjusted to pause by default for the session of the page (as to not pause every song) when on cell data or a restricted network. This would allow people to still stream audio without touching settings, and without being a hassle... but it would still protect the 95+% of us who would never want to stream over a data connection (as we don't even have the option to subscribe to an appropriate data plan for our phones). --- TL;DR: Data costs real money for people around the world, especially (but not only) when traveling. 1. Restrict data by default 2. Option for restricting data (turned on by default) 3. Allow a work-around in a tab session in the notification for background audio via notification.

Is it possible to track data usage on Firefox? This could clarify what is wasting all the data by generating a report. Also, it would allow setting a data limit per backgrounded tab. That way, music could still be played on background tabs (even if it wasn't fully buffered, giving it some bonus MB to finish when in background). When the limit is reached, Firefox could notify the user that a background tab is using much data, and ask whether to continue or "kill" it. "Kill" could be simply "unplugging the internet cable" for that tab while allowing JS et al to work (can this be done per tab, if at all?), or freezing/unloading the tab if that's not possible. (The notification would pop a bit early, say at 70%, giving the user some reaction time before blocking the tab automatically if no response is given.) All this, of course, only when the user's on mobile data. PS: Garrett, thanks for letting me know about restricting background data (apparently you can do it per app, so Firefox just lost its privilege after today's 500 MB).

Re-triaging per https://bugzilla.mozilla.org/show_bug.cgi?id=1473195 Needinfo :susheel if you think this bug should be re-triaged.

Searching around on the interwebs I was wondering if you can programmatically toggle the Android setting but it looks like it cannot be done. I wonder if a low tech way might be to have a shortcut to the app settings screen and instruct the user to toggle background mobile data off? It would be nice to try and leverage Android's built-in features more often.

... I also disable service workers, notifications +via both about:config and Android settings for the app). I also hope the new Firefox feature for the desktop to block slow running scripts is introduced to the Android app.

We have completed our launch of our new Firefox on Android. The development of the new versions use GitHub for issue tracking. If the bug report still reproduces in a current version of [Firefox on Android nightly](https://play.google.com/store/apps/details?id=org.mozilla.fenix) an issue can be reported at the [Fenix GitHub project](https://github.com/mozilla-mobile/fenix/). If you want to discuss your report please use [Mozilla's chat](https://wiki.mozilla.org/Matrix#Connect_to_Matrix) server https://chat.mozilla.org and join the [#fenix](https://chat.mozilla.org/#/room/#fenix:mozilla.org) channel.