1030353 - [B2G][General][OTA] OTA download does not pause on switch from 3G to 2G Network

Status: RESOLVED WONTFIX

(Firefox OS Graveyard :: General, defect)

Description

[Brogan Zumwalt [Inactive]]

Attachment: Logcat

Description: 
When user is downloading OTA update over 3G, switching from 3G to 2G network does not pause on switch. Download hangs for a moment, then continues downloading from 2G.

Repro Steps:
1) Update a Flame to 20140623000201
2) Force check for OTA update with 3G data connection
3) Begin OTA download
4) Launch Settings
5) Navigate to Cellular & Data > Network Operator > Network Type
6) Change network type to 2G Only
7) Pull down notification tray


Actual:
OTA download hangs briefly before continuing to download on 2G network with no user input.

Expected:
The package downloading process should be paused.

Environmental Variables:
Device: Flame 2.0
Build ID: 20140623000201
Gaia: 729f214b887ce8efe7d870145d31acb2c6427817
Gecko: 117ba3eda4d2
Version: 32.0a2 (2.0) 
Firmware Version: v121-2

User Agent: Mozilla/5.0 (Mobile; rv:32.0) Gecko/32.0 Firefox/32.0 

Notes:
Repro frequency: 3/3, 100%
See attached: Youtube video clip & logcat

Comment 1

[Brogan Zumwalt [Inactive]]

Issue DOES occur on 2.1 Flame, 1.4 Flame

Environmental Variables:
Device: Flame 2.1
Build ID: 20140624040203
Gaia: 45479c07cb6ba8c733093d6ee32c767c090c9a28
Gecko: e86b84998b18
Version: 33.0a1  
Firmware Version: v121-2

User Agent: Mozilla/5.0 (Mobile; rv:33.0) Gecko/33.0 Firefox/33.0


Environmental Variables:
Device: Flame 1.4
Build ID: 20140624000202
Gaia: 1d52323cd5b6c7d646f444712c81777d34f74e36
Gecko: 4e9d3d4412f9
Version: 30.0 (1.4) 
Firmware Version: v121-2

User Agent: Mozilla/5.0 (Mobile; rv:30.0) Gecko/30.0 Firefox/30.0 

Actual Result: OTA download hangs briefly before continuing to download on 2G network with no user input.

Buri testing blocked by bug 1029932
Open C testing blocked by bug 1007439
No OTA updates available for Flame Base (v121-2) unable to test branch

Comment 2

[Brogan Zumwalt [Inactive]]

Youtube link to video: http://youtu.be/laTqoyJ0kbo

Comment 3

[Brogan Zumwalt [Inactive]]

Link to test case: https://moztrap.mozilla.org/manage/case/10493/

Comment 4

[KTucker [:KTucker][Inactive 3/4/2016]]

Please update the 2.1 and 1.4 tracking flags.

Comment 5

[Jason Smith [:jsmith]]

See comment 4

Comment 6

[Dave Hylands [:dhylands]]

Hmm.

This sounds like a new feature. I'm pretty sure it isn't a regression.

Right now, when the network goes offline, it retries several times before cancelling the update. Although switching from 3G to 2G might not even involve an ip-address change, in which case, from the updaters perspective, the network didn't even go offline.

I'm going to guess that if you start the download on Wifi and switch to 3G/2G that it would also continue work with no user intervention.

Currently, I don't think that the updater even knows what type of network its on (2G/3G/Wifi) - but I could be wrong on this.

Comment 7

[Shih-Chiang Chien [:schien] (UTC+8) (use ni? plz)]

Detecting network type can be done in system app. Bug 827786 did something similar in the past. We could trigger "update-download-cancel" mozContentEvent and Gecko pause the download eventually.

Comment 8

[Jayme Mercado [:JMercado] (Inactive 3/4/2016)]

These same results occur when switching from Wifi to a 2G network.

Actual: The download does not pause when switching to 2G from wifi.

Expected: The download does pause when switching to 2G from wifi.

Comment 9

[Jason Smith [:jsmith]]

This still needs to go through the QAnalyst-Triage process.

Comment 10

[Joshua Mitchell (Inactive)]

not nomming, seems like low impact