880680 - [MMS] Transparently retrieve MMS when the data APN the same as MMS APN.

Status: RESOLVED DUPLICATE of bug 884829

(Core :: DOM: Device Interfaces, defect)

Description

[isabelrios]

Attachment: Trying to download

Seen on Unagi with today's build (06/07)
Gecko-7af1737
Gaia-b5937ae

PROCEDURE
In Setting-> Cellular & Data -> Message settings set Auto retrieve to 'Off'
Cellular data is off
1. From another device send an MMS to unagi device
2. On unagi device, open the MMS and tap on 'Download'

EXPECTED
There should be a warning/error message to let user know that the download can no be successfull till data connection is on

ACTUAL
It looks like the device tries to download the file, the spinner appears and never stops. No error or warning message is shown.
Please see screenshot attached

Comment 1

[bhavana bajaj [:bajaj]]

needsinfo ayman here to help check the spec and outline if this is expected behavior as per the current spec or a bug ?

Comment 2

[ayman maat :maat]

hey bhavana / Isabel

ok, my understanding is that this bug will be dependent on: https://bugzilla.mozilla.org/show_bug.cgi?id=862764

I believe that the behavior of Data Settings will be country specific and dictated by a setting in the build which the user will not see.

The desired flow for Telefonica is:

1) open settings app 
2) set Auto retrieve to OFF
3) set Cellular Data to OFF
4) send an MMS with attachment to the Unagi device from a second device
5) On the Unagi open the Messages app and navigate to the newly received message which should be informing the user that a file is available to download
6) Select the Download CTA

***EXPECTED***

7) The data connection will automatically open temporarily to allow the download of the attachment. However no notification will be given to the end user that the Data connection had been opened
8) When the download is complete the data connection will automatically close. However no notification will be given to the end user that the Data connection had been closed

putting Beatrice on CC on this bug to check that I am correct with my interpretation of requirements. Feel free to correct me if i have got the requirements wrong so bhavana has a clear picture of the desired behavior.

Comment 3

[Paul Yang [:pyang] (away)]

Retry takes about 30 minutes and then fail.  Need info. to clarify how long it takes during execution
Need info ctai to make sure retry mechanism.

Comment 4

[Chia-hung Tai [:ctai :ctai_mozilla :cht]]

Please see bug 840066:

 Peter Dolanjski [:pdol] 2013-02-11 07:17:33 PST

UCID: Messages-044

User Story:
As a user, I will not have to manually retry downloads if the download of media attached to an MMS message fails. Should a download of media fail the application will automatically retry downloading the content a minimum of four times when the network is active at intervals of 1, 5, 10, and 30 minutes, and an indication that content downloads are in progress will be presented to me. Should the content download fail, the failure should be anounced to me in the form of a message notification in the inbox to simplify the viewing of MMS message status for me.

Comment 5

[Julien Wajsberg [:julienw]]

I thought we could have either one "sending" event for each retry (maybe add a "sendingRetry" counter to the message), or a "retry" event for each retry. This way the UI could react to these events.

Does that make sense ?

Comment 6

[Dietrich Ayala (:dietrich)]

Ayman, comment #0 says that a notification should show the user that data is not on. Bug 862764 will do that, and is a blocker.

As reported, we should just dupe this bug against bug 862764.

Does that sound right to you?

Can you take any other issues (such as auto-enable data, etc) to new/different bugs?

Comment 7

[ayman maat :maat]

(In reply to Dietrich Ayala (:dietrich) from comment #6)
> Ayman, comment #0 says that a notification should show the user that data is
> not on. Bug 862764 will do that, and is a blocker.
> 
> As reported, we should just dupe this bug against bug 862764.
> 
> Does that sound right to you?
> 
> Can you take any other issues (such as auto-enable data, etc) to
> new/different bugs?

Hey Dietich

No please dont Dupe this bug against bug 862764

bug 862764 is describing the behavior when sending an MMS and this bug is describing the behavior when receiving an MMS. These are two different cases.

Comment 8

[Beatriz Rodríguez [:brg]]

(In reply to Chia-hung Tai [:ctai :ctai_mozilla :cht] from comment #4)
> Please see bug 840066:
> 
>  Peter Dolanjski [:pdol] 2013-02-11 07:17:33 PST
> 
> UCID: Messages-044
> 
> User Story:
> As a user, I will not have to manually retry downloads if the download of
> media attached to an MMS message fails. Should a download of media fail the
> application will automatically retry downloading the content a minimum of
> four times when the network is active at intervals of 1, 5, 10, and 30
> minutes, and an indication that content downloads are in progress will be
> presented to me. Should the content download fail, the failure should be
> anounced to me in the form of a message notification in the inbox to
> simplify the viewing of MMS message status for me.

This bug is not about the automatic retry download mechanism when a failure is detected but about the suitable behaviour when cellular data is off and the auto retrieve is off.

Comment 9

[Julien Wajsberg [:julienw]]

If I follow comment 2, this is more a gecko-side bug.

Comment 10

[Alex Keybl [:akeybl]]

Over to ctai to reassign

Comment 11

[Chia-hung Tai [:ctai :ctai_mozilla :cht]]

Actually this bug is depend on bug 837488. Once bug 837488 be landed, this bug will be resolved like bug 862764.

Comment 12

[Beatriz Rodríguez [:brg]]

(In reply to Chia-hung Tai [:ctai :ctai_mozilla :cht] from comment #11)
> Actually this bug is depend on bug 837488. Once bug 837488 be landed, this
> bug will be resolved like bug 862764.
Bug 837488 is not nominated so it will not land properly, right? then those two issues will not be fixed in current situation.

Comment 13

[Julien Wajsberg [:julienw]]

I nominated there (note: you could have to ! ;) )

Comment 14

[Chia-hung Tai [:ctai :ctai_mozilla :cht]]

According to comment2, 7, change the summary.

Comment 15

[Ken Chang[:kenkai]]

Change the depends on bugs list, since the bug 837488 doesn't block this bug now.

Comment 16

[Ken Chang[:kenkai]]

According to the summary and comment 11, this bug has the same root cause with bug 884829.

Comment 17

[Ken Chang[:kenkai]]

This bug has same root cause with bug 884829.