Most of cellular networks do not support DTM (Dual Transfer Mode), that means that a device using 2G data cannot receive incoming calls or make outgoing calls. If we offer the user the option to do an OTA update when in 2G Data the experience would be awful: long time to do the update and long time in which no calls will be received. I'd suggest we simply do not offer the customer the option to start an update when in 2G.

there's a lot of conditions here that would need to be defined first before deciding if this is bb?. - what happens if a user switches from 2G to 3G or wifi in the middle of a download? - when does the update get ping'ed? - whats the http request data payload on the ping? - is there notification message that we want to show the user? - does this apply to 3rd party app updates? (given the updater UI is collaborated with system updates) Fwiw, i tested a 50Mb system update over Edge in America, and it took about 15-20 minutes to successfully download. it's long, but not unbearably long. I also could use the device for other services during the download time.

Seems like we could have a simple Gaia-level solution to suppress the update notification when network == 2G?

(In reply to Lucas Adamski from comment #2) > Seems like we could have a simple Gaia-level solution to suppress the update > notification when network == 2G? This doesn't address the case that Tony identified where a user transitions from wifi or 3G to 2G during a download. I think the suggestion is actually to pause the download in this case and resume when the user has a non 2G connection. I can see a Gaia level workaround to prompt the user that it is preferable to perform the update over a fast data connection like wifi or 3G. Is that acceptable for v1?

I guess we'll also have to actively cancel the download if we switch to 2G too. Are we positive that when the WifiManager.connection.status != 'connected' we're using the DATA connection?

Late incoming feature but still a v1 issue.

(In reply to Lucas Adamski from comment #2) > Seems like we could have a simple Gaia-level solution to suppress the update > notification when network == 2G? If this the easiest and less risky solution, that should be good enough imo, but lmandel suggestion: > I can see a Gaia level workaround to prompt the user that it is preferable to perform the > update over a fast data connection like wifi or 3G. Is that acceptable for v1? That is also OK to me

(In reply to Lawrence Mandel [:lmandel] from comment #3) > I can see a Gaia level workaround to prompt the user that it is preferable > to perform the update over a fast data connection like wifi or 3G. Is that > acceptable for v1? Is downloading over 2g acceptable if the download started on 3g? If not, then I guess a prompt is required. Do we know if the network "offline" flag actually changes when switching between 3g / 2g network links? If so, the fix for Bug 819548 should handle this prompt..

Hi, I think we cannot allow any OTA download under 2G (neither starting in 3G and reselecting to 2G later on), as it has a huge impact for the users (several hours with the equipment being unable to receive any voice calls). Thanks, David

(In reply to Marshall Culpepper [:marshall_law] from comment #7) > (In reply to Lawrence Mandel [:lmandel] from comment #3) > > I can see a Gaia level workaround to prompt the user that it is preferable > > to perform the update over a fast data connection like wifi or 3G. Is that > > acceptable for v1? > > Is downloading over 2g acceptable if the download started on 3g? > I would say it is acceptable for 15 January. Let's file a follow-up bug to do it properly when we have time as David states in comment 8. Can we all agree to go with the simple option to warn the user about the possible issues with using 2G?

(In reply to Lawrence Mandel [:lmandel] from comment #3) > (In reply to Lucas Adamski from comment #2) > > Seems like we could have a simple Gaia-level solution to suppress the update > > notification when network == 2G? > > This doesn't address the case that Tony identified where a user transitions > from wifi or 3G to 2G during a download. I think the suggestion is actually > to pause the download in this case and resume when the user has a non 2G > connection. > > I can see a Gaia level workaround to prompt the user that it is preferable > to perform the update over a fast data connection like wifi or 3G. Is that > acceptable for v1? Does the download even survive these transitions? 3G to 2G perhaps, but wifi->2G? Downloads seem to hang if you even look at them funny. A simple warning or heuristic sounds fine for 1.0, I don't think we have time for anything more elaborate.

So we're going with just modifying the Gaia download prompt. If not on wifi -> message warning about the cost If not on wifi, and on 2G -> message warning about the cost and the missed calls

Final strings (done in coordination w/ Ricardo): > If not on wifi -> message warning about the cost String: "Wi-Fi unavailable. Updating over current connection may incur additional charges." > If not on wifi, and on 2G -> message warning about the cost and the missed calls String: "Wi-Fi unavailable. Updating over current connection will block incoming calls, and may incur additional charges."

Screenshots attached above. Please let me know if there are any questions.

Given the smaller scope of this prompt update this bug is being bumped to blocking-basecamp+. (gal says)

Comment on attachment 700113 [details] [diff] [review] Patch proposal Review of attachment 700113 [details] [diff] [review]: ----------------------------------------------------------------- ::: apps/system/js/wifi.js @@ +67,5 @@ > + // when wifi status change, emit event to notify StatusBar/UpdateManager > + wifiManager.onstatuschange = function onWifiDisabled() { > + var evt = document.createEvent('CustomEvent'); > + evt.initCustomEvent('wifi-statuschange', > + /* canBubble */ true, /* cancelable */ false, null); So Justin! <3

Comment on attachment 700113 [details] [diff] [review] Patch proposal r+ post-mortem so that you know that we're tracking this change.

Landed on mozilla-b2g18/gaia master prior to the 1/25 branching to mozilla-b2g18_v1_0_0/v1.0.0, updating status-b2g-v1.0.0 to fixed.

Verified fixed on Unagi build 20130219070200 Dec 5th kernel Update Channel:Nightly time to install OTA via 2g 25 minutes..sucessful

Additional comments: Gecko http://hg.mozilla.org/releases/mozilla-b2g18_v1_0_1/rev/98354c0298ab Gaia edaca00b1eb7534120b6255db5d5200fb1d86d65