Closed Bug 808595 Opened 12 years ago Closed 12 years ago

Firefox mobile (Nightly) doesn't obey 'only over Wifi' setting for downloading updates on Sunday/early Monday (MEZ)

Categories

(Firefox for Android Graveyard :: General, defect)

Product:
Firefox for Android Graveyard
Component:
General
Platform:
ARM
Android
Type:
defect
Priority:
Not set
Severity:
critical

Tracking

(firefox19- fixed, firefox20 verified)

Status:
VERIFIED FIXED
Milestone:
Firefox 20
Tracking Flags:
Tracking Status
firefox19 - fixed
firefox20 --- verified

People

(Reporter: whimboo, Assigned: snorp)

References

Details

Attachments

(1 file)

Use separate Intent for prompted vs automatic updates on Android
4.60 KB, patch
blassey
: review+
bajaj
: approval-mozilla-aurora+
Details | Diff | Splinter Review 
I have seen that a couple of times in the last days that the Nightly build of Fennec is downloading updates while I'm on my mobile connection. I'm not sure when exactly that happens, I get the update notification which I swipe away but at some point Fennec decides to download the update. Probably it happened when I turned on the auto-sync option?

I can't really further test it because it kills all my available mobile traffic. So if someone else could further investigate it, I would appreciate it.

I have not tested any Aurora or Beta builds so far. Seeing the status for bug 793276 we should expand testing on those builds. Asking for tracking Firefox 19 for now.
Product: Fennec → Firefox for Android
Btw. the build I have used is the one from yesterday.
Keywords: qawanted
(In reply to Henrik Skupin (:whimboo) from comment #1)
> Btw. the build I have used is the one from yesterday.

Are you sure? I recently pushed a fix for this issue (bug 805431).
The build is indeed after the patch on bug 805431 has been landed on m-c. But it's the build from Nov 2nd. Sorry for that.
Pretty weird. What phone is this on? I have mine set to wifi only and I haven't seen this.
It's a Nexus S with Android 4.1.2. So the place where I have seen this has a pretty unstable wifi network. It can be that Firefox checked for updates while wifi was there, but when it started to download the update my phone lost the connection. If that would be the case the following steps should demonstrate it:

1. Connect to Wifi and check for updates
2. Once the download has been started disconnect from wifi

After step 2 the download should stop and no more data should be transferred.
Not a release issue, since we don't utilize the updater in released code.
tracking-fennec: --- → ?
tracking-firefox19: ? → -
(In reply to Henrik Skupin (:whimboo) from comment #5)
> It's a Nexus S with Android 4.1.2. So the place where I have seen this has a
> pretty unstable wifi network. It can be that Firefox checked for updates
> while wifi was there, but when it started to download the update my phone
> lost the connection. If that would be the case the following steps should
> demonstrate it:
> 
> 1. Connect to Wifi and check for updates
> 2. Once the download has been started disconnect from wifi
> 
> After step 2 the download should stop and no more data should be transferred.

If that happened, the download would be interrupted and you'd see a "touch to retry" message (it does not retry automatically). I'm not sure what is going on here. It might help if you are able to capture the logcat output once you see that it started a download. You can use the following app to get at it on your phone: https://play.google.com/store/apps/details?id=org.jtb.alogcat&hl=en
tracking-fennec: ? → ---
tracking-firefox19: - → ?
Removing qawanted, we weren't able to reproduce with this testing in the other similar bug verifying it when this came up before.
Flags: needinfo?(hskupin)
Keywords: qawanted
So my phone reports again about 47MB of mobile traffic for Nightly today. Not sure when that happened but it's clearly background data. I haven't used Nightly at all today so there can't be an overlap. What I could see is a notification that an updated version of Firefox is available for download. But I haven't touched it, so no download of an update should have happened.
Flags: needinfo?(hskupin)
Something which is interesting is that I filed this bug last week on Monday. Exactly 1 week ago. Now it happened again. So why I can only see this once in a week?
(In reply to Henrik Skupin (:whimboo) from comment #9)
> So my phone reports again about 47MB of mobile traffic for Nightly today.
> Not sure when that happened but it's clearly background data. I haven't used
> Nightly at all today so there can't be an overlap. What I could see is a
> notification that an updated version of Firefox is available for download.
> But I haven't touched it, so no download of an update should have happened.

If it says that it is "touch to download" that means it has not downloaded it yet. If it says "touch to update", then it has already downloaded it. It sounds like maybe it has not in fact downloaded it automatically?

Do you have sync enabled? That's another place where background data can be used.
(In reply to James Willcox (:snorp) (jwillcox@mozilla.com) from comment #11)
> Do you have sync enabled? That's another place where background data can be
> used.

No. Sync has not been setup on my phone. Is there an android application you can propose which logs network traffic for individual apps and lists that by time? That would be kinda helpful for me to figure our more details, e.g. when I left the wifi zone, etc.
So I can confirm it again. Once in a week between Sunday evening and Monday morning my time (GMT+1) Firefox downloads the update via my mobile connection even when I haven't triggered it. The data usage app shows another 46MB of background data usage. In the notification area I see the following message:

Downloading Nightly
Touch to apply update once downloaded

So I'm not sure what's happening here. Do we have another code path which could trigger such an update whether if you are connected to wifi or not? I kinda feels so.
tracking-fennec: --- → ?
Summary: Firefox mobile (Nightly) doesn't obey 'only over Wifi' setting for downloading updates → Firefox mobile (Nightly) doesn't obey 'only over Wifi' setting for downloading updates on Sunday/early Monday (MEZ)
Do you have FF beta installed? That's on a weekly update cycle and might be interfering here.
Yeah there has to be something else going on here. It doesn't make sense at all for Nightly to behave differently on Sunday specifically...
No, Firefox Beta is not installed on that device.
I have autodownload set to never, and have been seeing updates sometimes being downloaded unattended both before and after the commit for bug 805431, but I haven't been able to catch it in the act or figure out a pattern.

It feels like it happens more often when I clear the update notification instead of ignoring it, but I could just be making that up.

Samsung Galaxy S i9000 on Android 2.3.3, sync disabled, no other Firefoxen installed.
Ok, I know what's happening here now. Working on a patch.
Assignee: nobody → snorp
Status: NEW → ASSIGNED
The problem here is that we accidentally overwrote the PendingIntent that scheduled update checks use with the one that is used when you acknowledge that you want to apply an available update. The difference was just an extra flag, but that was erroneously sticking around for the scheduled update checks as well. The patch uses a different intent for the prompted case to avoid any badness like this.
Attachment #684018 - Flags: review?(blassey.bugs) → review+
Thanks James! I'm looking forward to get it tested next Sunday/Monday. I'm sure we can get it landed before that day.
https://hg.mozilla.org/mozilla-central/rev/6b05a49691ae
Status: ASSIGNED → RESOLVED
Closed: 12 years ago
Resolution: --- → FIXED
Target Milestone: --- → Firefox 20
Haven't seen this reported behavior anymore in the last two weeks. Marking as verified.
Status: RESOLVED → VERIFIED
status-firefox20: --- → verified
This never hit Aurora and it's at least hurting one user in bug 824796.
Comment on attachment 684018 [details] [diff] [review]
Use separate Intent for prompted vs automatic updates on Android

[Approval Request Comment]
Fixes nasty update bug for Aurora, low-risk, baked on m-c for quite a while
Attachment #684018 - Flags: approval-mozilla-aurora?
Attachment #684018 - Flags: approval-mozilla-aurora? → approval-mozilla-aurora+
tracking-fennec: ? → ---
Product: Firefox for Android → Firefox for Android Graveyard
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: