User Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:55.0) Gecko/20100101 Firefox/55.0 Build ID: 20170727114534 Steps to reproduce: For some reason, Firefox decided to use 7.81 GB of background data overnight, putting me over my data cap shared with two other people. I had 3 web pages open overnight. http://robertsrules.org https://pbs.twimg.com/media/DG3l21AUIAIbb6H?format=jpg https://m.imgur.com/mcwtNVo Actual results: Firefox used 7.81 GB of background data with three web pages open. Expected results: Firefox should not have used 7.81 GB of background data.

The second screenshot shows how the data shows up as "Background data". So a possible workaround could be to disable background data for Firefox - this is what I have done to hopefully prevent this happening again.

Hello, I'm sorry but I was not able to reproduce this issue. Could you please provide some more information (Device & Android Version you're using, any addons that you have installed). It is not possible for Firefox to use that much data with only the specified pages open. Are you sure you didn't download by mistake any large files using Firefox?

Device is OnePlus 3t Android version 7.1 Only add-on installed is ublock Origin. I am quite sure that I didn't download any large files. If I have, wouldn't that data usage have shown as foreground data and not background data? The screenshots I have provided show quite clearly the sudden spike in data usage and the culprit : Firefox using 7.81 GB of background data.

At the time, were you logged into Firefox Account? Did you have syncing enabled? If so, what data types (history, bookmarks..) were you syncing? (I'm not aware of anything that _might_ cause sync to use so much data, but it would be good to rule that out).

I don't use the Firefox Account or Sync features, so neither of those features were enabled at the time of the issue.

So, I've left https://imgur.com/mcwtNVo open for two minutes in a browser without an ad-blocker running, and the page managed to download about 5mb of data (and made something like 4500 network requests) from all the ads and trackers reloading. Over 8 hours, that's roughly 2gb of data usage, which puts us into the right order of magnitude. (as I'm writing this message, it's up to 10mb and 7800 requests) Perhaps ublock origin running on Fennec will help here, but that likely depends on how it's configured, etc. Sebastian, I vaguely recall similar bugs in the past, but IIRC they were to do with videos auto-playing. Do we have anything logged/have discussed similar behaviour before?

The imgur link is their gifv format, which is actually mp4 under the hood - see https://help.imgur.com/hc/en-us/articles/208606616-What-is-GIFV- Given that it actually is an autoplaying video, not a gif, perhaps I'm still running into the autoplaying videos issue you mentioned?

The "auto-play" issue which I recalled involved a website playing a different video after the current one finishes. That is, video which browser didn't already have in its cache, and must download. The offending website would keep doing this for hours, eating up tons of bandwidth. In your case, I expect that the mp4 video in question is only downloaded once. It would be good to verify that this is actually the case in Fennec. However, the ads on this page are just pure evil :-( In Comment 7, it was just those ads reloading that accounts for all the consumed data.

(In reply to :Grisha Kruglov from comment #7) > Sebastian, I vaguely recall similar bugs in the past, but IIRC they were to > do with videos auto-playing. Do we have anything logged/have discussed > similar behaviour before? Yeah, we have discussed this before and were thinking about ways to make data usage at least visible. The tricky part is that some users explicitly want to have videos and audio continue to play in the background. As we are now displaying a media notification whenever we play something I wonder whether we could/should "pause" a tab that is in the background and *not* playing anything. Anyhow I redirect this to snorp - whatever we decide to do - we need the platform team. :)

Grisha, We have a setting called "Allow auto play" in the "Setting" -> "Advanced..". Can you try that to see if it is helpful?

(In reply to Sebastian Kaspari (:sebastian) from comment #10) > (In reply to :Grisha Kruglov from comment #7) > > Sebastian, I vaguely recall similar bugs in the past, but IIRC they were to > > do with videos auto-playing. Do we have anything logged/have discussed > > similar behaviour before? > > Yeah, we have discussed this before and were thinking about ways to make > data usage at least visible. The tricky part is that some users explicitly > want to have videos and audio continue to play in the background. As we are > now displaying a media notification whenever we play something I wonder > whether we could/should "pause" a tab that is in the background and *not* > playing anything. Anyhow I redirect this to snorp - whatever we decide to do We are thinking of similar thing in Bug 1386280. :-)

(In reply to Blake Wu [:bwu][:blakewu] from comment #11) > We have a setting called "Allow auto play" in the "Setting" -> "Advanced..". > Can you try that to see if it is helpful? I think A/V controls are great, but for this bug it's not the video that's killing us, it's the ad fetches from the page staying alive. We need to completely pause pages in the background. The influence of A/V here is that we don't want to zombify your NPR radio page. Sebastian's point is that we might be able to do this now that we show media playback notifications -- perhaps even heavyweight by zombifying everything shortly after background, and letting the user resume playback (and wake the tab) if they want.

(In reply to Richard Newman [:rnewman] from comment #13) > (In reply to Blake Wu [:bwu][:blakewu] from comment #11) > > > We have a setting called "Allow auto play" in the "Setting" -> "Advanced..". > > Can you try that to see if it is helpful? > > I think A/V controls are great, but for this bug it's not the video that's > killing us, it's the ad fetches from the page staying alive. We need to > completely pause pages in the background. If those ads are auto play, it should not be allowed to play in the very beginning if the setting is "Allow auto play" is false. I am wondering if that setting works well or not. > > The influence of A/V here is that we don't want to zombify your NPR radio > page. Sebastian's point is that we might be able to do this now that we show > media playback notifications -- perhaps even heavyweight by zombifying > everything shortly after background, and letting the user resume playback > (and wake the tab) if they want. Agree. It is what I thought after posting the comment as well. Actually, this is what Chrome is doing right now. They automatically pause media when Chrome enters the background but user can resume it via their media control. I think we can do that as well but that would change our current behavior. We may need UX/PM's feedback here.

@Grisha: Did you test with the desktop or the mobile page? I saw some self-refreshing ads on the desktop page (although I don't think at quite the same rate as in your case), but the mobile page didn't seem quite as bad in that respect. (In reply to Blake Wu [:bwu][:blakewu] from comment #14) > They automatically pause media when > Chrome enters the background but user can resume it via their media control. > I think we can do that as well but that would change our current behavior. (In reply to Richard Newman [:rnewman] from comment #13) > The influence of A/V here is that we don't want to zombify your NPR radio > page. Sebastian's point is that we might be able to do this now that we show > media playback notifications -- perhaps even heavyweight by zombifying > everything shortly after background, and letting the user resume playback > (and wake the tab) if they want. Stopping inaudible/silent media is fine [1], but I think that interrupting *audible* playback every time a tab is backgrounded has the potential to be rather annoying. Besides, I'm not really sure why there's this focus on media playback here all of a sudden, when we don't even know what exactly has gone wrong. If Grisha's theory is correct and it was in fact some ad script having gone haywire, then that could have happened on any page, even one that wasn't playing any media, right (although we should at least be throttling script timeouts on background tabs that aren't playing anything audible)? Also Richard, do you mean zombifying as in https://dxr.mozilla.org/mozilla-central/rev/37b95547f0d27565452136d16b2df2857be840f6/mobile/android/chrome/content/browser.js#3825, or did you have something else in mind? [1] But that won't even be triggering the media control notification anyway, or will it? The video "GIF" on that Imgur page certainly doesn't.

(In reply to Jan Henning [:JanH] from comment #15) > Stopping inaudible/silent media is fine [1], but I think that interrupting > *audible* playback every time a tab is backgrounded has the potential to be > rather annoying. N.B., not each time a tab is backgrounded; if your screen is on and Firefox is open, NPR will continue to play while you read Reddit. The issue here is that a sleeping device -- screen off -- is doing work. The deciding event would be each time the browser is paused (onPause). > Besides, I'm not really sure why there's this focus on media playback here > all of a sudden… Because the most obvious fix for this bug is the big hammer "don't allow background pages to do stuff", disabling timers and fetch and so on, and that will -- without further attention -- squash background media playback at the same time. We're all just jumping ahead a little to the consequences of incapacitating background tabs. Probably we can come up with a good heuristic here: if the frontmost tab is playing audio, don't put it in deep freeze when the app pauses. For all other tabs, deep-freeze on pause, or soon after. > Also Richard, do you mean zombifying as in > https://dxr.mozilla.org/mozilla-central/rev/ > 37b95547f0d27565452136d16b2df2857be840f6/mobile/android/chrome/content/ > browser.js#3825, or did you have something else in mind? Background/inactive docshells do useful things like disable meta refresh, even if the browser still exists. (Bug 518805) 'course, it's 2017, so pages now use piles of JS instead of meta refresh, and that's essentially this bug: a background page is refreshing its content (ads) all night, and the work we did to make sure it couldn't reload itself is ignored.

Ah right, so not *that* kind of zombie tab, but attempting to disable all interesting stuff like JS execution, network access, etc. Thanks for the clarification, in that case (and with provisions for a tab that is playing audible media and showing the notification) the idea sounds fine.

(In reply to Richard Newman [:rnewman] from comment #16) > > Probably we can come up with a good heuristic here: if the frontmost tab is > playing audio, don't put it in deep freeze when the app pauses. For all > other tabs, deep-freeze on pause, or soon after. > That's fine, but what if it's the frontmost tab that causes the problem? This is a tough issue, but one we should probably try to do better on.

(In reply to James Willcox (:snorp) (jwillcox@mozilla.com) from comment #18) > That's fine, but what if it's the frontmost tab that causes the problem? > This is a tough issue, but one we should probably try to do better on. Yeah, I didn't mean my heuristic was necessarily finished :D In that case the audio playing notification will be present, and audio will most likely be playing. If you pause the audio for a while, presumably we should freeze the tab. Audio here is a proxy for the tab doing something useful, and when the tab's no longer useful, we should freeze it. If you play "sleep music" overnight, and the site loads 8GB of ads by morning, that's unfortunate, of course, but I'm not sure what we could do about that beyond per-tab data limits.

[triage] This will require a large time investment that I don't think we have eng resources for so prioritizing as non-critical P3. Susheel, please correct me if you think I'm mistaken. Note that this is an issue that we've been chasing for a while, yet haven't entirely fixed yet.

(In reply to Michael Comella (:mcomella) [please needinfo for a response] from comment #20) > [triage] This will require a large time investment that I don't think we > have eng resources for so prioritizing as non-critical P3. Susheel, please > correct me if you think I'm mistaken. Note that this is an issue that we've > been chasing for a while, yet haven't entirely fixed yet. Mike, indeed, there are policy questions wrapped up with technical strategies here, so until we have a PM who adjudicates beyond all those choices (Andreas), we have to leave it as a P3.

I suppose Android's built-in "data saving" mode (which restricts background data) would have helped in this particular scenario. It would be interesting to tackle this issue and find a good solution for it, but now is probably not the right time. I'd like to somehow keep track of this issue for when we'll focus on data saving optimizations though - is there a good way to tag this so that we can resurface it when needed?

Andreas yeah I'm not a Bugzilla master, but I created a '[data-savings]' whiteboard tag. I wonder if there is any easy way to see all the different whiteboard tags?

Closing per https://bugzilla.mozilla.org/show_bug.cgi?id=1473195 Contact :susheel if you think this bug should be re-opened