1097440 - [FFOS2.0][Woodduck][Download]Download failed when change SIM card network to wifi during downloading

Status: RESOLVED WONTFIX

(Firefox OS Graveyard :: Gaia::System, defect, P2)

Description

[sync-1]

Reporter's phone number:TEL: [phone]  ext：63432 		
 
  DEFECT DESCRIPTION:
 [Download]Download failed when change SIM card network to wifi during downloading
 
  REPRODUCING PROCEDURES:
 1.Insert SIM card into phone and enabled data connection;
 2.Go to http://imps.tcl-ta.com/liuqiong/media/e5.html and try to download a big file;
 3.Enter Settings,enabled wifi and connect router normally and turn off data connection,then download failed===>KO
 
 Note:子安在过程中如果是wifi向data network转换，则能正常从停止点继续下载
 
  EXPECTED BEHAVIOUR:
 handset can resume downloading from the break point
 
  ASSOCIATE SPECIFICATION:
 
  TEST PLAN REFERENCE:
 
  TOOLS AND PLATFORMS USED:
 
  USER IMPACT:
 
  REPRODUCING RATE:
 
  For FT PR, Please list reference mobile's behavior:

Comment 1

[sync-1]

Attachment: video

Comment 2

[sync-1]

Attachment: log

Comment 3

[Josh Cheng [:josh]]

Hi Shawn,
Can you check Woodduck can handle data hand over correctly? Thanks!

Comment 4

[Josh Cheng [:josh]]

Hi Norry,
qawanted for Woodduck 2.0M and Flame 2.0/2.1/2.2. Thanks!

Comment 5

[Norry.L.F(Leave from Mozilla)]

Attachment: Verify.mp4

Hi Josh,
This bug can be repro on Woodduck 2.0M and Flame 2.0/2.1/2.2.During downloading, if switch from WIFI to GPRS, it works normally, but if switch from GPRS to Wifi, the downloading will be fail.

Attached verify.mp4 & logcatVerify.txt
Found time: 17:04
Rate: 100%

Woodduck versions:
Gaia-Rev        6f224862dbab92638a0bf58cd0150fb4a242ef86
Gecko-Rev       ad825202335b517f37d44f22b4d6c04a25c557d6
Build-ID        20141112050313
Version         32.0

Flame 2.0 versions:
Gaia-Rev        dfdd6268b9784eafdd509f0ddf71407698ed5080
Gecko-Rev       https://hg.mozilla.org/releases/mozilla-b2g32_v2_0/rev/fcc5d31f84d7
Build-ID        20141111000205
Version         32.0

Flame 2.1 versions:
Gaia-Rev        7154f9aa0a69af56c8bd89be0c98d9791449527b
Gecko-Rev       https://hg.mozilla.org/releases/mozilla-b2g34_v2_1/rev/452db1a0c9a0
Build-ID        20141111001201
Version         34.0

Flame 2.2 versions:
Gaia-Rev        5f8206bab97cdd7b547cc2c8953cadb2a80a7e11
Gecko-Rev       https://hg.mozilla.org/mozilla-central/rev/d380166816dd
Build-ID        20141110040206
Version         36.0a1

Comment 6

[Norry.L.F(Leave from Mozilla)]

Attachment: logcatVerify.txt

Comment 7

[Vincent Chang[:vchang][changyihsin]]

Not sure if service.io.offline doesn't have right value in NetworkManager when connection state transition. Will check and update the result later.

Comment 8

[shawn ku [:sku]]

Hi Vincent:
 ni you to keep status tracking.

Comment 9

[Edgar Chen [:edgar]]

(In reply to Vincent Chang[:vchang] from comment #7)
> Not sure if service.io.offline doesn't have right value in NetworkManager
> when connection state transition. Will check and update the result later.

I have quick checked the service.io.offline, it is updated as expected.

But I found one interesting behavior,
1. For Wifi -> 3G case, the offline will be set to `true` first then `false`.
   (Because gecko connection 3G after wifi connection is dropped, so there will be a small period
    that device has no active network)
2. For 3G -> Wifi case, the offline will keeps in `false` unchanged,
   (Gecko drops the 3G connection after wifi is connected)

I guess the error handling (for socket error?) are different in avoid two scenario.

Hi Jason, could you kindly shed me some light here? Thank you.

Comment 10

[Jason Duell]

Daniel, do you know the NetworkManager bits here well enough to say what's going on in comment 9?

Comment 11

[Daniel Stenberg [:bagder]]

It sounds like the good old changing network problem. Switching between two network interfaces is not necessary being "offline" (as long as at least one interface is present) so it shouldn't have to go that state, but TCP connections that are open and in use over an interface that goes stale will stop working.

This sounds like a situation that the network change events could help. Bug 1008091 is pending for b2g. It would be interesting to hear if running with this patch changes the behavior for this situation as it is certainly meant to.

Comment 12

[sync-1]

hi mozilla：
 按照1008091提交的patch,编译时报错：
 /local/soul35_mtk/gecko/netwerk/system/linux/nsNotifyAddrListener_Linux.cpp: In member function 'void nsNotifyAddrListener::OnNetlinkMessage(int)':
 /local/soul35_mtk/gecko/netwerk/system/linux/nsNotifyAddrListener_Linux.cpp:128:19: error: 'NS_NETWORK_LINK_DATA_CHANGED' was not declared in this scope
 
 无法进行验证

Comment 13

[Daniel Stenberg [:bagder]]

(In reply to sync-1 from comment #12)

>  /local/soul35_mtk/gecko/netwerk/system/linux/nsNotifyAddrListener_Linux.cpp:
> In member function 'void nsNotifyAddrListener::OnNetlinkMessage(int)':
>  /local/soul35_mtk/gecko/netwerk/system/linux/nsNotifyAddrListener_Linux.cpp:
> 128:19: error: 'NS_NETWORK_LINK_DATA_CHANGED' was not declared in this scope

That define is present in netwerk/base/public/nsINetworkLinkService.idl in mozilla-central. Which tree are you trying the patch on? You need the patch applied on a tree where the patch series for Bug 939318 is present.

Comment 14

[sync-1]

hi mozilla:
    please merged PR 939318 and PR 1008091 modified patch on branch 2.0M.thanks

Comment 15

[sync-1]

hi mozilla:
    please merged PR 939318 and PR 1008091 modified patch on branch 2.0M.thanks

Comment 16

[Josh Cheng [:josh]]

(In reply to Daniel Stenberg [:bagder] from comment #13)
> (In reply to sync-1 from comment #12)
> 
> >  /local/soul35_mtk/gecko/netwerk/system/linux/nsNotifyAddrListener_Linux.cpp:
> > In member function 'void nsNotifyAddrListener::OnNetlinkMessage(int)':
> >  /local/soul35_mtk/gecko/netwerk/system/linux/nsNotifyAddrListener_Linux.cpp:
> > 128:19: error: 'NS_NETWORK_LINK_DATA_CHANGED' was not declared in this scope
> 
> That define is present in netwerk/base/public/nsINetworkLinkService.idl in
> mozilla-central. Which tree are you trying the patch on? You need the patch
> applied on a tree where the patch series for Bug 939318 is present.

Hi Daniel,
Partner need this for 2.0M branch. I think Bug 939318 is fixing on 2.1 Do you think it is possible to land both patch from bug 939318 and but 1008091 on 2.0M? Thanks!

Comment 17

[Daniel Stenberg [:bagder]]

Possible? Certainly! But...

First, bug 1008091 has not landed anywhere yet due to the outstanding test failures.

Then, the patch series for bug 939318 (6 patches) were subsequently bugfixed in bug 1024614 and bug 1077084 so they'll be required as well.

I did some quick checks right now and there are some annoying merge conflicts that need to be handled, but they seem manageable.

Comment 18

[sync-1]

hi mozilla:
    Do you merged the patch (PR 939318 and PR 1008091 modified patch) on 2.0M ?

Comment 19

[Peipei Cheng (needinfo if you need my action)]

(In reply to sync-1 from comment #18)
> hi mozilla:
>     Do you merged the patch (PR 939318 and PR 1008091 modified patch) on
> 2.0M ?

No we haven't merged them yet.

Per comment 17, bug 1008091 has not been landed anywhere yet due to the outstanding test failures.

Comment 20

[Josh Cheng [:josh]]

Discussed with DengWei and decide to postpone fix on 2.2. Not fix on 2.0M.