1106468 - [Midori 2.0][Download][DSW]if the file which stop to download by hand or is Failed to Download can automatically continue to download

Status: RESOLVED WONTFIX

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

Description

[sync-1]

FFOS2.0 baseline BuildID: 20140916000205
 
 DEFECT DESCRIPTION:
 if the file is stop to download by hand or is Failed to Download,then switch wifi to the data,or reopen the wifi when the data is close,you will find the file Automatically continue to download 
 REPRODUCING PROCEDURES:
 1.open data connection,and open wifi
 2.lanuch “http://imps.tcl-ta.com/cailiang/media/bigFile.html”
 3.open “Big Video(468M) ”
 4.choose "save video" when the menu pop up by long press the interface
 5.drag down the statue bar ,and click the notification to steo into download
 6.stop the download by hand
 7.drag down the statue bar 
 8.close wifi
 9.then you will find the staying file Automatically continue to download--->ko1
 10.open wifi,close data
 11.close wifi,open wifi
 12.then you will find the failing file Automatically continue to download--->ko2
 
 
 
 EXPECTED BEHAVIOUR:
 KO1&ko2: The manual stoped or download failed file can auto-recover to downloading status.
 
 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

[sync-1]

Attachment: log

Comment 2

[sync-1]

Attachment: video

Comment 3

[sync-1]

Attachment: log

Comment 4

[ChengLin.Wu]

[Blocking Requested - why for this release]:

Comment 5

[Shine(Leave from Mozilla)]

Hi,
Is this bug reproducible in 1.3 SW?
The expected behavior: "KO1&ko2: The manual stoped or download failed file can auto-recover to downloading status.", seems that it is the same with bug actual behavior, please confirm the expected behavior again.
Thanks!

Comment 6

[ChengLin.Wu]

(In reply to Shine from comment #5)
> Hi,
> Is this bug reproducible in 1.3 SW?
> The expected behavior: "KO1&ko2: The manual stoped or download failed file
> can auto-recover to downloading status.", seems that it is the same with bug
> actual behavior, please confirm the expected behavior again.
> Thanks!

Dears,
The download manager is not support on 1.3.   

I confirmed the expected behavior:
The manual stoped or download failed file can not auto-recover to downloading status

Comment 7

[ChengLin.Wu]

(In reply to sync-1 from comment #0)
> FFOS2.0 baseline BuildID: 20140916000205
>  
>  DEFECT DESCRIPTION:
>  if the file is stop to download by hand or is Failed to Download,then
> switch wifi to the data,or reopen the wifi when the data is close,you will
> find the file Automatically continue to download 
>  REPRODUCING PROCEDURES:
>  1.open data connection,and open wifi
>  2.lanuch “http://imps.tcl-ta.com/cailiang/media/bigFile.html”
>  3.open “Big Video(468M) ”
>  4.choose "save video" when the menu pop up by long press the interface
>  5.drag down the statue bar ,and click the notification to steo into download
>  6.stop the download by hand
>  7.drag down the statue bar 
>  8.close wifi
>  9.then you will find the staying file Automatically continue to
> download--->ko1
>  10.open wifi,close data
>  11.close wifi,open wifi
>  12.then you will find the failing file Automatically continue to
> download--->ko2
>  
>  
>  
>  EXPECTED BEHAVIOUR:
>  KO1&ko2: The manual stoped or download failed file can auto-recover to
> downloading status.
>  
>  ASSOCIATE SPECIFICATION:
>  TEST PLAN REFERENCE:
>  TOOLS AND PLATFORMS USED:
>  USER IMPACT:
>  REPRODUCING RATE:
>  5/5
>  For FT PR, Please list reference mobile's behavior:

EXPECTED BEHAVIOUR:
 KO1&ko2: The manual stoped or download failed file can not auto-recover to
downloading status.

Comment 8

[Shine(Leave from Mozilla)]

Attachment: Flame2.1&2.2 video

This bug cannot be repro on Flame 2.1/2.2
See attachment: Flame2.1&2.2_video.MP4
Reproducing rate: 0/5

Flame 2.1 build:
Gaia-Rev        dbaf3e31c9ba9c3436e074381744f2971e15c7bf
Gecko-Rev       https://hg.mozilla.org/releases/mozilla-b2g34_v2_1/rev/ebce587d2194
Build-ID        20141203001205
Version         34.0

Flame 2.2 build:
Gaia-Rev        725685831f5336cf007e36d9a812aad689604695
Gecko-Rev       https://hg.mozilla.org/mozilla-central/rev/2c9781c3e9b5
Build-ID        20141203040207
Version         37.0a1

Comment 9

[ChengLin.Wu]

(In reply to Shine from comment #8)
> Created attachment 8531821 [details]
> Flame2.1&2.2 video
> 
> This bug cannot be repro on Flame 2.1/2.2
> See attachment: Flame2.1&2.2_video.MP4
> Reproducing rate: 0/5
> 
> Flame 2.1 build:
> Gaia-Rev        dbaf3e31c9ba9c3436e074381744f2971e15c7bf
> Gecko-Rev      
> https://hg.mozilla.org/releases/mozilla-b2g34_v2_1/rev/ebce587d2194
> Build-ID        20141203001205
> Version         34.0
> 
> Flame 2.2 build:
> Gaia-Rev        725685831f5336cf007e36d9a812aad689604695
> Gecko-Rev       https://hg.mozilla.org/mozilla-central/rev/2c9781c3e9b5
> Build-ID        20141203040207
> Version         37.0a1

Dears,

This bug is related with bug 1106220.  When bug 1106220 occurs, this bug can be reproduce.

Comment 10

[ChengLin.Wu]

Dears,

Bug 1106220 effect this bug.

Comment 11

[Wesly Huang (EPM)]

[Triage] de-nom. given the user impact level. Also this is not seen in 2.1 and 2.2 per comment#8.

Comment 12

[Beatriz Rodríguez [:brg]]

[Blocking Requested - why for this release]: This is a certification blocker. If user manually stops/cancel the download, the device cannot resume it automatically. It had impact in user tarification.

Comment 13

[Wesly Huang (EPM)]

qawanted for 2.0 and 2.0M, since this will be blocker for woodduck as well.

Comment 14

[Chris Kreinbring [:CKreinbring]]

Unable to repro on Flame 2.0 engineering with shallow flash.
Actual results: Stopped downloads remain stopped regardless of status changes to WiFi and data connections.

BuildID: 20141212170645
Gaia: f3b9806f687fbbd7eba6b0e1f6ebb8bde09840ea
Gecko: 28bacbc71efb
Platform Version: 32.0
Firmware Version: V188-1
User Agent: Mozilla/5.0 (Mobile; rv:32.0) Gecko/32.0 Firefox/32.0

Leaving qawanted tag for 2.0M repro attempt.

Comment 15

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

Norry could you please help test on Woodduck 2.0 per comment 13. Thanks.

Comment 16

[Sue]

Attachment: woodduck_verify.MP4

This issue can not be repro on Woodduck 2.0M, it can't save video when run step 4.
See attachment: woodduck_verify.MP4

Woodduck versions:
Gaia-Rev        09097552f236b1482ce469b4c7d92d80d0706f83
Gecko-Rev       aa9ece9c8a749095834e7a980166543d985a3af5
Build-ID        20141217050313
Version         32.0
Device-Name     jrdhz72_w_ff
FW-Release      4.4.2
FW-Incremental  1418763978
FW-Date         Wed Dec 17 05:06:44 CST 2014

Comment 17

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

Thank you, Sue.

Comment 18

[Beatriz Rodríguez [:brg]]

After checking Flame 2.0 behaviour(Gecko-b6ef05b.Gaia-ce83ea7) with today build, I cannot reproduce this issue with Mozilla branch. The download is not automatically resumed in data or wifi after having stopped it. Removing the nomination accordingly.

Comment 19

[sync-1]

The new ref is updated by  with patch_delivery script!
 
     ###%%%comment:[Email]Optimize Exchange smart-forward/smart-reply
     ###%%%bug number:858353
     ###%%%product name:SW.JrdApp
     ###%%%root cause:Coding
     ###%%%Bug category:TCT
     ###%%%Generated by:
     ###%%%regression response:---
     ###%%%regression comments:
     ###%%%Module_Impact:Email
     ###%%%Test_Suggestion:
     ###%%%Solution:fix the limit to exchange which support smartfowrd reply
     ###%%%Test_Report:ok
     ###%%%VAL Can Test:Yes
 
 
 Branch: refs/heads/Email_Rel3_02
 http://172.16.11.162:8081/#change,228769
 http://172.16.11.162/gitweb.cgi?p=genericapp/JrdEmail.git;a=commit;h=e1dd77f501e881d824859560fd93fdb435037c24

Comment 20

[BMO Automation]

Firefox OS is not being worked on