1106220 - [Midori 2.0][Download][DSW] it can continue download if you switch wifi to 3G ,but it will download fail directly if yo switch3G to wifi

Status: RESOLVED WONTFIX

(Firefox OS Graveyard :: Gaia::Browser, defect, P1)

Description

[sync-1]

FFOS2.0 baseline BuildID: 20140916000205
 
 
 DEFECT DESCRIPTION:
 it can continu download if you switch wifi to the data ,but it will download
 fail directly if yo switch the data to wifi
 REPRODUCING PROCEDURES:
 1.open "data connection",connect the wifi
 2.lanuch "http://imps.tcl-ta.com/cailiang/media/bigFile.html”
 3.open “Big Video(468M) ”
 4.choose "save video" which should you long press the interface to pop up the
 menu
 5.close wifi
 6.it can continue to download by the data
 7.open wifi
 8.it will remind user the downloading fail directly--->KO1
 
 
 
 ASSOCIATE SPECIFICATION:
 TEST PLAN REFERENCE:
 TOOLS AND PLATFORMS USED:
 USER IMPACT:
 REPRODUCING RATE:
 5/5
 For FT PR, Please list reference mobile's behavior:

Comment 1

[ChengLin.Wu]

[Blocking Requested - why for this release]:

Comment 2

[Shine(Leave from Mozilla)]

Hi, 
Is this bug reproducible in 1.3 SW?
Could you please provide the repro video and logcat, thanks!

Comment 3

[ChengLin.Wu]

(In reply to Shine from comment #2)
> Hi, 
> Is this bug reproducible in 1.3 SW?
> Could you please provide the repro video and logcat, thanks!

Dears,

This is a new feature on 2.0. The download manager is not support on 1.3.

Comment 4

[ChengLin.Wu]

Attachment: IMG_1117.MOV

Comment 5

[ChengLin.Wu]

There is a same problem on flame2.0.

Comment 6

[ChengLin.Wu]

When switch to wifi, there is a connection timeout exception.
I catch follow log:

I/Gecko   (  212): -*- DownloadsAPI.js : update ({totalBytes:491633683, currentBytes:24189524, url:"http://imps.tcl-ta.com/cailiang/media/longmovies.mp4", path:"/storage/sdcard/downloads/longmovies(2).mp4", contentType:"video/mp4", startTime:(new Date(1417498876040)), id:"download-0", state:"stopped", error:{name:"DownloadError", result:2152398862, message:"[Exception... \"The connection has timed out\"  nsresult: \"0x804b000e (NS_ERROR_NET_TIMEOUT)\"  location: \"JS frame :: resource://gre/modules/DownloadCore.jsm :: this.DownloadError :: line 1238\"  data: no]", becauseSourceFailed:true, becauseTargetFailed:false, stack:"this.DownloadError@resource://gre/modules/DownloadCore.jsm:1266:3\nDCS_execute/task_DCS_execute/backgroundFileSaver.observer.onSaveComplete@resource://gre/modules/DownloadCore.jsm:1583:17\n"}})
I/Gecko   (  212): -*- DownloadsAPI.js : Dispatching statechange event. state=stopped

Comment 7

[Shine(Leave from Mozilla)]

Attachment: Flame2.1&2.2 video

The bug can be repro on Flame 2.1 and 2.2.
See attachments: Flame2.1&2.2_video.MP4 & Flame2.1_logcat_1744.txt & Flame2.2_logcat_1744.txt
Reproducing rate: 0/5

Flame2.1 build:
Gaia-Rev        ccb49abe412c978a4045f0c75abff534372716c4
Gecko-Rev       https://hg.mozilla.org/releases/mozilla-b2g34_v2_1/rev/18fb67530b22
Build-ID        20141201001201
Version         34.0

Flame2.2 build:
Gaia-Rev        39214fb22c203e8849aaa1c27b773eeb73212921
Gecko-Rev       https://hg.mozilla.org/mozilla-central/rev/08be3008650f
Build-ID        20141201040205
Version         37.0a1

Comment 8

[ChengLin.Wu]

Dears,

If this pr reproduce. I resume and stop the failed downloading.  When I turn down and turn off wifi, the stopped downloading will resume automatically. effect bug 1106468 and bug 1106475.

Comment 9

[Wesly Huang (EPM)]

[Blocking Requested - why for this release]:

[Triage] not critical impact since user could expect download interrupt when switch wifi/data, nom. to 2.1 per comment#7 but not 2.0 given its timing.

Comment 10

[Beatriz Rodríguez [:brg]]

[Blocking Requested - why for this release]:
Renom to 2.0 because this is a certification blocker. Download should never be interrupted between data/wifi. User will expect delays but not 100% failure. This behaviour is not accepted in certification.

Comment 11

[Wesly Huang (EPM)]

[Triage]

tag since it's a TEF certification blocker.

qawanted for 2.0M since this will be blocker for woodduck too, if exist.

Comment 12

[Pi Wei Cheng [:piwei] (inactive)]

QA-Wanted team in QAnalysts don't have a Woodduck device. NI Norry for Woodduck testing.

Comment 13

[Shine(Leave from Mozilla)]

Hi PiWei,
The bug can be repro on Woodduck 2.0.
See attachments: Woodduck_logcat_1251.zip & Woodduck_video.MP4
Reproducing rate: 0/5

Woodduck 2.0 build:
Gaia-Rev        1f082dae21f60735e20669b4dcfddc39383b4ccf
Gecko-Rev       e3dc9e5cba07c956e34f03fc0b8fcd2342d57234
Build-ID        20141216050313
Version         32.0

Comment 14

[Shine(Leave from Mozilla)]

Attachment: logcat

Comment 15

[Shine(Leave from Mozilla)]

Attachment: video

Comment 16

[Pi Wei Cheng [:piwei] (inactive)]

(In reply to Shine from comment #13)
> Hi PiWei,
> The bug can be repro on Woodduck 2.0.

Thanks for testing on Woodduck to fulfill the qawanted request.

Comment 17

[shawn ku [:sku]]

Should try to rebase 2.0 trunk once 1008091 get landed.

Comment 18

[Keven Kuo [:kkuo]]

Hi! Shawn,

Could someone of your team help to rebase to 2.0 and 2.1?
Thanks

--
Keven

Comment 19

[shawn ku [:sku]]

2.0m/2.1s are requested via below.
https://bugzilla.mozilla.org/show_bug.cgi?id=1008091#c67

Comment 20

[Gregor Wagner [:gwagner]]

What are the next steps here?

Comment 21

[Keven Kuo [:kkuo]]

(In reply to shawn ku [:sku] from comment #19)
> 2.0m/2.1s are requested via below.
> https://bugzilla.mozilla.org/show_bug.cgi?id=1008091#c67

There is a dependency on bug 939318 and 1008091 is follow-up fix.
Due to high risk. Wontfix on 2.0, 2.0m, 2.1 and 2.1s.

--
Keven

Comment 22

[BMO Automation]

Firefox OS is not being worked on