960789 - [B2G][Messaging]MMS messages are automatically downloaded when data conection is disabled.

Status: RESOLVED WONTFIX

(Firefox OS Graveyard :: RIL, defect)

Description

[Ross Kuhlman ([e-mail])]

Attachment: logcat.txt

Device is set to automatically download MMS messages, but WiFi and Data Connection are both disabled. A MMS message is sent to the device, and the device automatically downloads the content, even though 
Data Connection is disabled.

Repro Steps:
Prerequisites: Data Connection, Data Roaming, and WiFi are all disabled. In Messaging Settings, Auto Retrieve is set to 'on with roaming'.

1) Updated Buri to BuildID: 20140115004003
2) Send a MMS message with text to the device under test. (Send from different device)
3) Recieve and observe message on device under test.

Actual:
MMS content and text are both automatically downloaded.

Expected:
Text is downloaded, but MMS content will not download until Data Connection is enabled.

Environmental Variables:
Device: Buri v1.3 Moz RIL
BuildID: 20140115004003
Gaia: 14e199d6a9ad917eacad883820a9f7619dbf42c8
Gecko: d7260b206e91
Version: 28.0a2
Firmware Version: v1.2-device.cfg

Notes:

Repro frequency: 100%
Link to failed test case: https://moztrap.mozilla.org/manage/case/6674/
See attached: logcat.

Comment 1

[Ross Kuhlman ([e-mail])]

Issue does not occur in v1.2.
Environmental Variables:
Device: Buri v1.2 Moz RIL
BuildID: 20140114004002
Gaia: 539a25e1887b902b8b25038c547048e691bd97f6
Gecko: 42a1c35fc831
Version: 26.0
Firmware Version: v1.2-device.cfg

The message is not downloaded. The user must reactivate data connection and manually restart download.

Comment 2

[gbennett]

Repro's on the oldest stable 1.3 build and as stated in comment 1 it does not occur on latest 1.2

Environmental Variables:
Device: Buri 1.3 MOZ
BuildID: 20130919040201
Gaia: 0dedb5b3789afc638a0c7c67652937fcb30e77d2
Gecko: 803189f35921
Version: 27.0a1
Firmware Version: v1.2-device.cfg

Comment 3

[Jason Smith [:jsmith]]

I'm guessing this is likely a RIL bug, rather than a UI bug.

Comment 4

[Hsin-Yi Tsai (she/her) [:hsinyi]]

(In reply to rkuhlman from comment #0)
> Created attachment 8361358 [details]
> logcat.txt
> 
> Device is set to automatically download MMS messages, but WiFi and Data
> Connection are both disabled. A MMS message is sent to the device, and the
> device automatically downloads the content, even though 
> Data Connection is disabled.
> 

Hi, 

If user set 'auto-retrieve' mode for MMS, then no matter 'Data connection' is enabled or not, we are going to automatically set up mms connection for auto-retrieving the content. 'Data connection' is only for default type data call, having nothing to do with mms.


 
> Repro Steps:
> Prerequisites: Data Connection, Data Roaming, and WiFi are all disabled. In
> Messaging Settings, Auto Retrieve is set to 'on with roaming'.
> 
> 1) Updated Buri to BuildID: 20140115004003
> 2) Send a MMS message with text to the device under test. (Send from
> different device)
> 3) Recieve and observe message on device under test.
> 
> Actual:
> MMS content and text are both automatically downloaded.
> 
> Expected:
> Text is downloaded, but MMS content will not download until Data Connection
> is enabled.
> 
> Environmental Variables:
> Device: Buri v1.3 Moz RIL
> BuildID: 20140115004003
> Gaia: 14e199d6a9ad917eacad883820a9f7619dbf42c8
> Gecko: d7260b206e91
> Version: 28.0a2
> Firmware Version: v1.2-device.cfg
> 
> Notes:
> 
> Repro frequency: 100%
> Link to failed test case: https://moztrap.mozilla.org/manage/case/6674/
> See attached: logcat.

Comment 5

[Bevis Tseng[:bevis][:btseng](Exited)]

Just test it locally with Helix 1.2 latest build.
The behavior looks different:
The MMS download can be downloaded correctly with data connection set to 'OFF' and Auto Retrieve set to 'on with roaming'.

--
https://pvtbuilds.mozilla.org/pvt/mozilla.org/b2gotoro/nightly/mozilla-b2g26_v1_2-helix/latest/                                                    
ENG Ver: false                                                           
Flash: Gaia, Gecko,                                                      

Gaia      539a25e1887b902b8b25038c547048e691bd97f6
Gecko     http://hg.mozilla.org/releases/mozilla-b2g26_v1_2/rev/27e469d3cab0
BuildID   20140116004003
Version   26.0
ro.build.version.incremental=eng.wanglei.20131212.005845
ro.build.date=Thu Dec 12 00:58:58 CST 2013

Comment 6

[Jason Smith [:jsmith]]

So are we claiming the behavior in 1.2 was a bug, while the behavior in 1.3 is the correct behavior? Just trying to understand if this is a legitimate bug or not.

Comment 7

[Bevis Tseng[:bevis][:btseng](Exited)]

Attachment: Script to enable RIL/MMS logs.

The behavior in 1.2 on that device seems not expected.

We need the log with RIL/MMS tags enabled in 1.2 build to know what's difference on that device under the specific network.

Need help to capture the log after executing the attached script on the test device.

Thanks!

Comment 8

[Jason Smith [:jsmith]]

(In reply to Bevis Tseng [:bevistseng] ([e-mail]) from comment #7)
> Created attachment 8361548 [details]
> Script to enable RIL/MMS logs.
> 
> The behavior in 1.2 on that device seems not expected.
> 
> We need the log with RIL/MMS tags enabled in 1.2 build to know what's
> difference on that device under the specific network.
> 
> Need help to capture the log after executing the attached script on the test
> device.
> 
> Thanks!

Why? We aren't supporting the 1.2 branch anymore, so doing any analysis at this point on that branch doesn't really have value.

If this is a bug on 1.2, but doesn't reproduce on 1.3, then this bug probably needs to be closed as a won't fix.

Comment 9

[Bevis Tseng[:bevis][:btseng](Exited)]

Thanks for reminding the supporting status of 1.2.

I'd like to change to status to WONTFIX first since the behavior in 1.3 is expected.

We can file another bug for further discussion/analysis if the expected behavior is needed to be changed or the MMS cannot be downloaded correctly when data connetion is OFF in 1.3/master branch.

Comment 10

[Julien Wajsberg [:julienw]]

Yeah, I agree with all this too, this is the expected behavior.

Comment 11

[Julien Wajsberg [:julienw]]

Roland, since this is the expected behavior, I think you should update your test cases?