Closed Bug 880680 Opened 8 years ago Closed 7 years ago

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

Categories

(Core :: DOM: Device Interfaces, defect)

x86_64
Windows 7
defect
Not set
normal

Tracking

()

RESOLVED DUPLICATE of bug 884829
blocking-b2g leo+

People

(Reporter: isabelrios, Assigned: kchang)

References

Details

(Whiteboard: MMS_TEF)

Attachments

(1 file)

Attached image 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
needsinfo ayman here to help check the spec and outline if this is expected behavior as per the current spec or a bug ?
Flags: needinfo?(aymanmaat)
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.
Depends on: 862764
Flags: needinfo?(aymanmaat) → needinfo?(brg)
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.
Flags: needinfo?(ctai)
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.
Flags: needinfo?(ctai)
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 ?
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?
Flags: needinfo?(aymanmaat)
(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.
Flags: needinfo?(aymanmaat)
(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.
Flags: needinfo?(brg)
blocking-b2g: leo? → leo+
Depends on: 884739
If I follow comment 2, this is more a gecko-side bug.
Component: Gaia::SMS → DOM: Device Interfaces
Product: Boot2Gecko → Core
Over to ctai to reassign
Assignee: nobody → ctai
Actually this bug is depend on bug 837488. Once bug 837488 be landed, this bug will be resolved like bug 862764.
Depends on: 837488
No longer depends on: 862764
(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.
I nominated there (note: you could have to ! ;) )
According to comment2, 7, change the summary.
Summary: [MMS] Trying to download a file received with no connection never result in an error/warning to user → [MMS] Transparently retrieve MMS when the data APN the same as MMS APN.
No longer depends on: 837488
Change the depends on bugs list, since the bug 837488 doesn't block this bug now.
Depends on: 884829
According to the summary and comment 11, this bug has the same root cause with bug 884829.
Assignee: ctai → kchang
This bug has same root cause with bug 884829.
Status: NEW → RESOLVED
Closed: 7 years ago
Resolution: --- → DUPLICATE
Duplicate of bug: 884829
You need to log in before you can comment on or make changes to this bug.