878360 - [MMS] Showing manual download UI when auto-retrieving is turn-on

Status: RESOLVED WONTFIX

(Firefox OS Graveyard :: Gaia::SMS, defect)

Description

[Paul Yang [:pyang] (away)]

Gaia:     e7fd566656c3ad01fff04270b973f3e23d006c31
Gecko:    http://hg.mozilla.org/releases/mozilla-b2g18/rev/6ca32ed2bbc6

Precondition:
1 phone which can send MMS message
1 Fxos phone

REPRODUCE STEPS:
1. Turn off auto-retrieving
2. Send MMS message from another phone
3. Check message app, wait for incoming message
4. Message incoming with a download button.  valid period is specified.
5. Turn on auto-retrieving
6. Tap download button in message

EXPECT:
1. Start to download MM payload.
2. Spin icon disappeared after download finished
3. Another incoming message with MM

ACTUAL:
1. Spin icon never end, even download is not started
2. Download button can't be tapped.
3. No MMS message downloaded eventually

Comment 1

[Paul Yang [:pyang] (away)]

Reproduce on leo device
Flash base image from LG, 20130524

Comment 2

[Gene Lian (I already quit Mozilla)]

Recently, we had a couple of fixes at Bug 810099 (reopen) and Bug 879152, which would stop us retrieving MMS. Those issues might be related.

Comment 3

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

Please attach the log with debug messages.

adb remount
adb pull /system/b2g/defaults/pref/user.js user.js
[update user.js with adding 'pref("ril.debugging.enabled", true);' 'pref("mms.debugging.enabled", true);']
adb push user.js /system/b2g/defaults/pref/user.js
adb shell reboot

Thanks.

Comment 4

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

The retry mechanism do 4 times and might waiting over 40 minutes. MMSC might be temporally unavailable. So this case might happen when the MMSC temporally unavailable(HTTP STATUS 503, which I saw that before), and you don't wait over 40 minutes. You will think it is spin forever. After offline talked with Paul, it didn't happen very often. So it only happened once and worked fine over ten times. This match the assumption of MMSC temporally unavailable. But if Paul can reproduce it and get the log, I can confirm what I think is correct or not.

Comment 5

[Paul Yang [:pyang] (away)]

rm user.js 2>/dev/null
adb remount
adb pull /system/b2g/defaults/pref/user.js user.js
sed -i -e '$ a\
pref("ril.debugging.enabled", true);\
pref("mms.debugging.enabled", true);
' user.js
adb push user.js /system/b2g/defaults/pref/user.js
adb shell reboot

## update for replacing user.js script

Comment 6

[Paul Yang [:pyang] (away)]

Attachment: log for spin forever when downloading

Comment 7

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

Per-talk...You turn on the data connection and bump in the bug 879225.
(In reply to Paul Yang from comment #6)
> Created attachment 758475 [details]
> log for spin forever when downloading

Comment 8

[Dietrich Ayala (:dietrich)]

Blocking for confirmation. This has to be solid.

Comment 9

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

Now I know how to reproduce it. There are some pre-conditions.
1. You are in the environment that not be able to receive MMS.
2. On auto-retrieving mode.
3. Send the message before first launching sms AP. You can reboot the phone and send the MMS during boot-up.

Then you will see the notification trying to download the MMS. If you still in the bad environment, you will see the error icon after about 15 minutes. If you enter a good environment, you can receive the message at final.

Now the question is shall we show the notification when auto-retrieving on?

Comment 11

[:gerard-majax]

Could it be my fault due to bug 882105 ? As far as I keep trying, after fixing bug 882105 I can't reproduce.

Comment 12

[:gerard-majax]

(In reply to Alexandre LISSY :gerard-majax from comment #11)
> Could it be my fault due to bug 882105 ? As far as I keep trying, after
> fixing bug 882105 I can't reproduce.

Nevermind, it seems unrelated and I just can't reproduce the issue.

Comment 13

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

Alex, 
This is hard to reproduce. You need to make your cellphone can't receive MMS by purpose. For me, I might mess up the MMS proxy and port. Then you have to send the MMS before your first launch of MMS.
And it is not related to bug 882105.

(In reply to Alexandre LISSY :gerard-majax from comment #12)
> (In reply to Alexandre LISSY :gerard-majax from comment #11)
> > Could it be my fault due to bug 882105 ? As far as I keep trying, after
> > fixing bug 882105 I can't reproduce.
> 
> Nevermind, it seems unrelated and I just can't reproduce the issue.

Comment 14

[Steve Chung [:steveck]]

(In reply to Chia-hung Tai [:ctai :ctai_mozilla :cht] from comment #9)
> Now I know how to reproduce it. There are some pre-conditions.
> 1. You are in the environment that not be able to receive MMS.
> 2. On auto-retrieving mode.
> 3. Send the message before first launching sms AP. You can reboot the phone
> and send the MMS during boot-up.
> 
> Then you will see the notification trying to download the MMS. If you still
> in the bad environment, you will see the error icon after about 15 minutes.
> If you enter a good environment, you can receive the message at final.
> 
> Now the question is shall we show the notification when auto-retrieving on?

It's not the notification. I think what you mean is the thread list in the thread list view. We will not popup any notification for not downloaded MMS while auto retrieving is on, but the not downloaded message is actually existing in database and it will be displayed in the thread list view, and it will display "message downloading..." in the bubble. I think it's a normal behavior for letting user know that message is downloading no matter the auto retrieving is on or off. The only difference is we don't pop notification while auto retrieving.

Comment 15

[Paul Yang [:pyang] (away)]

After investigation, this one is combined with bug 877433. When auto-retrieve is turned on, I see downloading UI which is only when manual download enabled. Because bug 877433, downloading never ends.
 I'd like to modify the title as "showing manual download UI when auto-retrieving is turn-on" since it is suitable to current situation.

Comment 16

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

voted leo-

(In reply to Steve Chung from comment #14)
> (In reply to Chia-hung Tai [:ctai :ctai_mozilla :cht] from comment #9)
> > Now I know how to reproduce it. There are some pre-conditions.
> > 1. You are in the environment that not be able to receive MMS.
> > 2. On auto-retrieving mode.
> > 3. Send the message before first launching sms AP. You can reboot the phone
> > and send the MMS during boot-up.
> > 
> > Then you will see the notification trying to download the MMS. If you still
> > in the bad environment, you will see the error icon after about 15 minutes.
> > If you enter a good environment, you can receive the message at final.
> > 
> > Now the question is shall we show the notification when auto-retrieving on?
> 
> It's not the notification. I think what you mean is the thread list in the
> thread list view. We will not popup any notification for not downloaded MMS
> while auto retrieving is on, but the not downloaded message is actually
> existing in database and it will be displayed in the thread list view, and
> it will display "message downloading..." in the bubble. I think it's a
> normal behavior for letting user know that message is downloading no matter
> the auto retrieving is on or off. The only difference is we don't pop
> notification while auto retrieving.

Comment 17

[Wayne Chang [:wchang]]

Triage - Partners agree to block

Comment 18

[Steve Chung [:steveck]]

Hi Ayman, we need your help to verify that how we deal with the message which download action is not completed when auto retrieving is on. Currently we will have "message downloading" with progress cursor to representing the message download behavior. Do we need to hide this message (or even the thread if the not-download message is in different thread) while auto retrieving mode is on?

Comment 19

[ayman maat :maat]

(In reply to Steve Chung from comment #18)
> Hi Ayman, we need your help to verify that how we deal with the message
> which download action is not completed when auto retrieving is on. Currently
> we will have "message downloading" with progress cursor to representing the
> message download behavior. Do we need to hide this message (or even the
> thread if the not-download message is in different thread) while auto
> retrieving mode is on?

Hey there Steve

I am sorry but I am not sure I fully understand your request. So to clarify: are you asking how to handle the presentation of a message module in the message thread where the download is for some reason stuck downloading when auto retrieve is on? or have i misinterpreted your request?

Comment 20

[Steve Chung [:steveck]]

(In reply to ayman maat :maat from comment #19)

> Hey there Steve
> 
> I am sorry but I am not sure I fully understand your request. So to clarify:
> are you asking how to handle the presentation of a message module in the
> message thread where the download is for some reason stuck downloading when
> auto retrieve is on? or have i misinterpreted your request?

Yes, the question is how we deal with the downloading message while auto retrieve is on. If you think it's fine to leave the downloading message while auto retrieve is on, then we don't have to fix this issue; if you think we should not display the downloading bubble until message downloaded, we will need to do extra work to hide the downloading message while auto retrieve is on.

Comment 21

[ayman maat :maat]

(In reply to Steve Chung from comment #20)
> (In reply to ayman maat :maat from comment #19)
> 
> 
> Yes, the question is how we deal with the downloading message while auto
> retrieve is on. If you think it's fine to leave the downloading message
> while auto retrieve is on, then we don't have to fix this issue; 

so long as the process of downloading is actually taking place it seems ok to me to leave the 'downloading' message visible as it is feeding back to the end user that a process is occurring. If the download has errored, then we need to communicate the failure to the user

Comment 22

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

Close this bug because of comment 20 and 21.