1010690 - [Tarako][MMS][Notification] The notification of new MMS does not appear while playing music/video in foreground

Status: RESOLVED FIXED

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

Description

[Bingqing Li]

Attachment: logcat

Environment:
----------------------------------------------------------
Gaia      dbc2b00f538df1d93960794fbb52aa84f6f19483
Gecko     https://hg.mozilla.org/releases/mozilla-b2g28_v1_3t/rev/3b6c97b5fe8b
BuildID   20140514164005
Version   28.1
ro.build.version.incremental=eng.cltbld.20140514.202602
ro.build.date=Wed May 14 20:26:10 EDT 2014


Steps to reproduce:
----------------------------------------------------------
1. Keep playing music/video at foreground.
2. Send a MMS to DUT
   ---> The notification does not show while the music/video is being playing, and no text tone of new MMS either.

3. Wait for a few minutes, exit Music/Video, and launch SMS
   ---> The new MMS is already in the list, and the the received time is about a few minutes ago.


Additional info
-------------------------------------------
Can not find any info about low memory kill in the log attached.
(In the log attached, the received time of the MMS is about 13:53)

Comment 1

[Steven Yang [:styang]]

Hi Steve, could you help to check this issue? thanks.

Comment 2

[Tzu-Lin Huang [:dwi2][:tzhuang]]

I could reproduce it. I add some debug log to get more information. Debug patch is https://github.com/dwi2/gaia/compare/mozilla-b2g:v1.3t...bug1010690_v1.3t

I saw that when receiving MMS while Music at foreground, document.hidden was false. 

E/GeckoConsole( 3904): Content JS LOG at app://sms.gaiamobile.org/gaia_build_defer_message-sms-received.js:200 in dispatchNotification: [Bug 1010690] dispatch notification: needManualRetrieve = false, document.hidden = false

And in activity handler, it just vibrated and returned without sending notification. Because we consider document.hidden == false means SMS app is in foreground. See https://github.com/mozilla-b2g/gaia/blob/v1.3t/apps/sms/js/activity_handler.js#L372 

So the question is: why document.hidden is false at that moment?

Comment 3

[Julien Wajsberg [:julienw]]

So it looks like it's a System issue then. Steve won't know why document.hidden is false ;)

Comment 4

[Steven Yang [:styang]]

Hi Alive, could you spare some time to look into this issue? thanks.

Comment 5

[Gregor Wagner [:gwagner]]

It's not OOM so it might not be tarako specific. Can we check other versions as well? 1.3, 1.4 and 2.0?

Comment 6

[Ross Kuhlman ([e-mail])]

Notification is displayed onscreen and device vibrates when receiving an MMS while Music is playing. Audio alert does not play.

Issue DOES repro on 2.0 and 1.4. Issue does NOT repro on 1.3

Device: Open C v2.0 Master M-C Mozilla RIL
BuildID: 20140516040203
Gaia: 7973e06dc278f67b4109ac3c33020ed086f0d042
Gecko: 58c5a3427997
Version: 32.0a1
Firmware Version: P821A10V1.0.0B06_LOG_DL

Device: Open_C 1.4
BuildID: 20140516000201
Gaia: 32fca83da31b9a0f9a5a88f96c913a25accdc14b
Gecko: a1e455367fa6
Version: 30.0
Firmware Version: P821A10V1.0.0B06_LOG_DL

Device: Buri 1.3 MOZ
BuildID: 20140514024003
Gaia: 96e3fa769a436a2182e6d54088fb41386eb2b5b5
Gecko: 685cf1d0dedb
Version: 28.0
Firmware Version: v1.2-device.cfg

Comment 7

[(inactive after 6/18) Alive Kuo [:alive]]

I can reproduce..could we have the regression window?

Comment 8

[(inactive after 6/18) Alive Kuo [:alive]]

What I see:
Message app should be launched at background when new sms comes and gaia system does set the visibility of message app to false. But for some reason the page visibility of message app is foreground. I don't know what happens still.

Comment 9

[Tim Guan-tin Chien [:timdream] (please needinfo)]

Set flag according to comment 6.

Comment 10

[Tim Guan-tin Chien [:timdream] (please needinfo)]

Alive, please work with platform devs if you believe this is a platform regression.

Comment 11

[Gregor Wagner [:gwagner]]

Jason, can we get some help with the regression window?

Comment 12

[Jason Smith [:jsmith]]

Yeah sure - jzimbrick can you get someone to look at this?

Comment 13

[Joe Cheng [:jcheng] (please needinfo)]

Hi Gregor, once the regression window is provided, can your team take a look at this bug? thanks

Comment 14

[Natalya Kot [:nkot]]

I believe the issue in comment 6 is different.

STR:
1) Play music on DUT
2) Receive MMS 

a) This bug:
- the user don't get any(!) notification for the MMS received but they will see the MMS when open Messages app
**Still reproducible on Tarako on the latest build,2/2 devices

b) Comment 6:
- the user receives some notification, no audio alert
**Cannot reproduce it on the latest Open_C 1.4 and trunk. 
1.4 receives MMS and notification just fine
on master MMS comes delayed no matter if the music plays or not, when MMS arrives the user receives notification for it (the delay receiving MMS should be reported separately)

Results confirmed on multiple devices.

'QAwanted' - see if you can find regression window on Tarako

Comment 15

[Julien Wajsberg [:julienw]]

Let's see if a) comes from bug 995907.

Comment 16

[Pi Wei Cheng [:piwei] (inactive)]

Harvey is working on this bug.

Comment 17

[Gregor Wagner [:gwagner]]

(In reply to Julien Wajsberg [:julienw] from comment #15)
> Let's see if a) comes from bug 995907.

Julien, any luck?

I will assign to Sam right now but feel free to reassign if we find a better owner.

Comment 18

[Julien Wajsberg [:julienw]]

(In reply to Gregor Wagner [:gwagner] from comment #17)
> (In reply to Julien Wajsberg [:julienw] from comment #15)
> > Let's see if a) comes from bug 995907.
> 
> Julien, any luck?

Actually I wait for the regression window to confirm/invalidate this guess.

Comment 19

[Harvey]

Tarako 1.3t Regression Window.

Last Working 
Environmental Variables: 
Device: Tarako 1.3t 
BuildID: 20140421030330 
Gaia: 3f1d8332d127f1d6bc0fdbb08146ce1deb0efbc0 
Gecko: 7b527e5a0c15 
Version: 28.1 
Firmware Version: SP6821a-Gonk-4.0-4-29 

First Broken
1.3t Environmental Variables: 
Device: Tarako 1.3t 
BuildID: 20140421120318 
Gaia: 3f1d8332d127f1d6bc0fdbb08146ce1deb0efbc0 
Gecko: 0b141ffd3b27 
Version: 28.1 
Firmware Version: SP6821a-Gonk-4.0-4-29

The Gaia is the same in both builds making this likely a Gecko issue

Gecko pushlog: http://hg.mozilla.org/releases/mozilla-b2g28_v1_3t/pushloghtml?fromchange=7b527e5a0c15%20&tochange=0b141ffd3b27

Comment 20

[Jason Smith [:jsmith]]

Can we double check the window here? The push log doesn't really make sense here, as it points to a patch that was landed & backed out.

Comment 21

[Lionel Mauritson]

I worked with Harvey to find a more likely window:

-Last Working-
Device: Tarako  
Build ID: 20140421161423
Gaia: 3f1d8332d127f1d6bc0fdbb08146ce1deb0efbc0
Gecko: 5da76152c2bd
Version: 28.1 
Firmware Version: SP6821a-Gonk-4.0-5-12

-First Broken-
Device: Tarako  
Build ID: 20140421170722
Gaia: 3f1d8332d127f1d6bc0fdbb08146ce1deb0efbc0
Gecko: 28526a158905
Version: 28.1 
Firmware Version: SP6821a-Gonk-4.0-5-12

Because the Gaia are the same we determined this to be a Gecko issue.

Gecko pushlog: http://hg.mozilla.org/releases/mozilla-b2g28_v1_3t/pushloghtml?fromchange=5da76152c2bd&tochange=28526a158905

Comment 22

[Gregor Wagner [:gwagner]]

That regression window doesn't make much sense if we just look at the gecko changes. 
Bug 977359 landed and got backed out again. The only gecko patch is from bug 993821. I dont think this is related.

Comment 23

[Sam Foster [:sfoster] (he/him)]

I /think/ what I'm seeing is that when the MMS notification fails to show up, the callback given in SMIL.parse(...) has never been called: https://github.com/mozilla-b2g/gaia/blob/v1.3t/apps/sms/js/activity_handler.js#L415

That points at https://github.com/mozilla-b2g/gaia/commit/a8f5ca74ce896569c601c6849d534ff9fa7ce8cb as a possible culprit? Or some other nearby change that breaks that expectation. With all the setTimeouts, nested callbacks and double-negatives in this code I'm not sure I'm following it properly though. I can keep poking at it if this sounds plausible?

Comment 24

[Jason Smith [:jsmith]]

Flagging again in hopes that we're going to make sure that we get the range right this time...

Comment 25

[Peter Bylenga [:PBylenga]]

We're seeing some intermittent behavior dependent on song file size and size of MMS being received.  Will investigate more tomorrow to see if we can get a solid regression window.

Comment 26

[Julien Wajsberg [:julienw]]

I've already seen cases where a setTimeout function was never called in some situations (especially when the phone was waking up), but it always happened in unsupported devices (like unagi) and so nobody never really worked on it.

But from comment 2, my own culprit was more [1]: document.hidden was false whereas it should be true in that case. I'll investigate on my side too, so keeping the NI.

[1] https://github.com/mozilla-b2g/gaia/blob/e76fc9fc64a027d84b2ec311fc624f4c3459dca9/apps/sms/js/activity_handler.js#L372

Comment 27

[Julien Wajsberg [:julienw]]

So, actually, I couldn't reproduce on my fairly recent build (~ start of this week). I used a Video that I captured before with the Camera, and a MP3 that I played with Music. I tried various MMS sizes too, with or without a subject. Each time, I received a notification, it vibrates, and I had the notification sound.

So I'll need a little more information on how you manage to reproduce it.

Comment 28

[Sam Foster [:sfoster] (he/him)]

Interesting. For me, the notification and vibrate is really sporadic. Its a tough one because of the variable timing involved in receiving the MMS. I've waited 5 minutes, assumed I'd reproduced then had it come in a minute later. I've even reproduced by just sitting on the homescreen - thought it never arrived then opened the sms app and the message is there.

Comment 29

[Peter Bylenga [:PBylenga]]

We were able to reproduce this on the first working tarako build we have available at about a 75% repro rate. We used 5-10 minute songs and tested with a picture MMS.  On the repro's we would not receive the notification until we switched to the Messaging app. Because of the intermittent behavior and the fact we can reproduce on the first Tarako build we are unable to find a solid regression window.

Environmental Variables:
Device: Tarako
BuildID: 20140403004001
Gaia: 8d212f640014db62c622e8c939ddbf8595f00438
Gecko: ddd7ba612cfe
Version: 28.1
Firmware Version: SP6821a-Gonk-4.0-4-29


We were also able to reproduce on the latest with a picture MMS and listening to a 5 minute song.

Environmental Variables:
Device: Tarako
BuildID: 20140523083621
Gaia: ffa388c3c00ee7a31216b397acaa07e1cf94bb39
Gecko: 15d65a48ce38
Version: 28.1
Firmware Version: SP6821a-Gonk-4.0-4-29

Comment 30

[Bingqing Li]

(In reply to Julien Wajsberg [:julienw] from comment #27)
> So, actually, I couldn't reproduce on my fairly recent build (~ start of
> this week). I used a Video that I captured before with the Camera

I tried on build 20140525164003. Here are the results:
-----------------------------------------------------------
1. When playing a video, which is captured with the Camera, in foreground, the notification works fine. 

   p.s. This video is about 5MB, lasts 3 minutes and 18 seconds.


2. When playing a video, which is copied to the device from pc, in foreground, the notification does not appear, it does not vibrate and there is no sound either. 

   p.s. This video is about 4MB, and lasts 3 minutes and 44 seconds. 
        The video type is 3gpp.


3. When playing a MP3 in foreground, the notification does not appear, it does not vibrate and there is no sound either. 

   p.s. This MP3 file is about 4MB, and lasts 4 minutes 22 seconds.


Julien,
If there is anything else you want to know, or anything you need me to provide, please let me know.

BTW, the latest PAC build can be found here: https://www.dropbox.com/sh/i38s2m4z2z69f66/AAA3ym8xgXSeH2B3m0EDaFF1a
The latest build is put under folder 2014-05-12. There are two pac files, one is user build, the other is eng build.

Comment 31

[Bingqing Li]

(In reply to Bingqing Li from comment #30)
Build Info
-----------------------------------------------------
Gaia      ffa388c3c00ee7a31216b397acaa07e1cf94bb39
Gecko     https://hg.mozilla.org/releases/mozilla-b2g28_v1_3t/rev/79eb01b64ed6
BuildID   20140525164003
Version   28.1
ro.build.version.incremental=eng.cltbld.20140525.202102
ro.build.date=Sun May 25 20:21:12 EDT 2014

Comment 32

[Julien Wajsberg [:julienw]]

Peter, you said the repro rate was about 75% on the first tarako build; can you find the repro rate on the latest build? Is it about the same?

Comment 33

[Julien Wajsberg [:julienw]]

What could happen: we release the WakeLock after 30 seconds, and the app is killed while it tries to read the message. We can try to increase the security timeout at [1] to eg 60 seconds and see if this fixes the issue.

If that's the issue, then I don't know where comment 2 comes from.

[1] https://github.com/mozilla-b2g/gaia/blob/d355042bd2a715162f8d568345d9e0ed7804c3ae/apps/sms/js/activity_handler.js#L321

Comment 34

[Jason Smith [:jsmith]]

QA Wanted to address comment 32.

Comment 35

[Julien Wajsberg [:julienw]]

Just tried once again with the same MP3 file. The MMS takes some time to arrive but it eventually does and then the notification is displayed.

I have the latest build (20140526014003) with the latest pac.
ro.build.version.incremental: eng.cltbld.20140526.051921
ro.build.date: Mon May 26 05:19:28 EDT 2014

I enable the Delivery Report option on the sending device so that I can monitor easily when the MMS has been completely delivered to the receiving device.


When you reproduce the issue, do you have any loaded data (Messages, Contacts), other applications, etc?

I'll try to reproduce again tonight.

Comment 36

[Bingqing Li]

(In reply to Julien Wajsberg [:julienw] from comment #35)
> When you reproduce the issue, do you have any loaded data (Messages,
> Contacts), other applications, etc?

No, there is no other loader data or applications. 

Here is the MP3 file that I used: https://www.dropbox.com/s/qa1iegzl74wb1sj/test.mp3

Here is the video that I used: https://www.dropbox.com/s/nd03d2otqviqo6g/H264_115.8_AMRnb_12.2_15f_5s_M_QCIF.3gp

Comment 37

[Julien Wajsberg [:julienw]]

If in step 3) of comment 0, you see the MMS in "pending" (means "undownloaded" mode, you don't see the message's content), and your message settings is "autodownload mms" then it's normal that you didn't get the notification yet, even if the message is in the list.

Still, the MMS should eventually autodownload and then you'll get the notification, but it can take several minutes.

I still can't reproduce it with the files in comment 36, sending a big MMS (about 300KB), so I am very tempted to close as WORKSFORME.

Comment 38

[Julien Wajsberg [:julienw]]

I confirm it can take several minutes though.

Comment 39

[Julien Wajsberg [:julienw]]

What definitely happened to me once is that the MMS was still not downloaded after 15 minutes. 

If that's the issue, then it's a RIL issue and we'll need more logs.


Also, I couldn't retrieve the MMS (my only SIM is in the 2nd slot) when clicking on Download (I get an error), I think I recall fixing something like this in 1.4...

Needinfo Bevis for 2 questions:

1. what log do you need to investigate about MMS that is not downloaded after lots of minutes?
2. calling retrieveMMS on a MMS that's been received on SIM 2 (serviceId: 1) with no SIM in SIM1 seems to not work on v1.3t.

Comment 40

[Gregor Wagner [:gwagner]]

(In reply to Julien Wajsberg [:julienw] from comment #39)
> Needinfo Bevis for 2 questions:
> 
> 1. what log do you need to investigate about MMS that is not downloaded
> after lots of minutes?
> 2. calling retrieveMMS on a MMS that's been received on SIM 2 (serviceId: 1)
> with no SIM in SIM1 seems to not work on v1.3t.

Thanks for investigating! Julien is a better owner here.

Comment 41

[Harvey]

I am NOT able to reproduce this issue on the latest Tarako build. 

Environmental Variables:
Device: Tarako
BuildID: 20140527060330
Gaia: c8f6ba7aa9a694f5f691555a0d049f5630cdde3d
Gecko: 8a45eba77e29
Version: 28.1
Firmware Version: SP6821a-Gonk-4.0-4-29

Comment 42

[Jason Smith [:jsmith]]

Actually we should also check 1.4 & 2.0 here, so leaving qawanted to see if this still occurs on 1.4 & 2.0.

Comment 43

[Peter Bylenga [:PBylenga]]

(In reply to Harvey from comment #41)
> I am NOT able to reproduce this issue on the latest Tarako build. 
> 
> Environmental Variables:
> Device: Tarako
> BuildID: 20140527060330
> Gaia: c8f6ba7aa9a694f5f691555a0d049f5630cdde3d
> Gecko: 8a45eba77e29
> Version: 28.1
> Firmware Version: SP6821a-Gonk-4.0-4-29

This is bizarre I checked on a second device and was able to reproduce the issue.  I then worked with Harvey and with his DUT from his early testing of 40 reproduction attempts and the issue reproduced immediately with sending a new text message to it.  We reproduced it on a third device as well, but on the fourth device it did not reproduce, we put Harvey's sd card in the phone, in order to use the same music file and the bug did not reproduce.

Will work with Harvey tomorrow to see if we can detect a pattern before a repro rate can be determined.

Comment 44

[Bingqing Li]

FYI
I cannot reproduce this issue on build 20140527014007. 
It's the same device that I used, and the only difference is the build.


Build Info
------------------------------------------------------------
Gaia      c8f6ba7aa9a694f5f691555a0d049f5630cdde3d
Gecko     https://hg.mozilla.org/releases/mozilla-b2g28_v1_3t/rev/bde42427e332
BuildID   20140527014007
Version   28.1
ro.build.version.incremental=eng.cltbld.20140527.053404
ro.build.date=Tue May 27 05:34:12 EDT 2014

Comment 45

[Joe Cheng [:jcheng] (please needinfo)]

can we confirm bug on the latest build from the partner side? ni James

Comment 46

[Bingqing Li]

(In reply to Julien Wajsberg [:julienw] from comment #37)
> If in step 3) of comment 0, you see the MMS in "pending" (means
> "undownloaded" mode, you don't see the message's content), and your message
> settings is "autodownload mms" then it's normal that you didn't get the
> notification yet, even if the message is in the list.
> 
> Still, the MMS should eventually autodownload and then you'll get the
> notification, but it can take several minutes.
> 
I tried on build 20140525164003, and here are the steps I did during the test:

1. Play music in foreground

2. Send a MMS with a picture to DUT, and the picture is about

3. Keep playing music in foreground for about 10 minutes
   --> Notification does not work. No sound, no indication in the status bar, and no vibrate either.

4. Goto SMS
   --> The new MMS is already in the list, and the the received time is about a few minutes ago.

5. Tap on the new MMS
   --> The picture is already downloaded. I can see the picture there.

But the strange thing is that I cannot reproduce this issue on build 20140527014007.

I'll upload another log if needed.

Comment 47

[James Zhang (Spreadtrum)]

I'll ask our QA to verify.

Comment 48

[Julien Wajsberg [:julienw]]

Each time you say you reproduce, I'd like to know which state the MMS you see is in: do you see the content, or do you see the "I have sent you a file. It will be available until ..." message?

Comment 49

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

(In reply to Julien Wajsberg [:julienw] from comment #39)
> What definitely happened to me once is that the MMS was still not downloaded
> after 15 minutes. 
> 
> If that's the issue, then it's a RIL issue and we'll need more logs.
> 
> 
> Also, I couldn't retrieve the MMS (my only SIM is in the 2nd slot) when
> clicking on Download (I get an error), I think I recall fixing something
> like this in 1.4...
> 
> Needinfo Bevis for 2 questions:
> 
> 1. what log do you need to investigate about MMS that is not downloaded
> after lots of minutes?
For network related issues, we need to capture the adb logcat & tcpdump as below:
https://github.com/bevis-tseng/Debug_Tools

> 2. calling retrieveMMS on a MMS that's been received on SIM 2 (serviceId: 1)
> with no SIM in SIM1 seems to not work on v1.3t.
May I know the STR for this? 
In current implementation, there are only 2 reasons that cause manual retrieval failure:
1. The default service Id is not the same to the one of the MMS to be retrieved.
2. The IccID of the MMS to be retrieved is not matched to the one of the inserted SIM.

Besides, after further discussion with the reporter offline and 
according to the reply in comment 46,
This bug is more related to the notification behavior after 
MMS is correctly downloaded (The content of the message is available)

If we have other issues regarding to MMS downloading, 
I'd like to suggest to fire new bugs to follow up instead.

Comment 50

[Bingqing Li]

(In reply to Julien Wajsberg [:julienw] from comment #48)
> Each time you say you reproduce, I'd like to know which state the MMS you
> see is in: do you see the content, or do you see the "I have sent you a
> file. It will be available until ..." message?

As I mentioned in comment 46, I sent a MMS with a picture, and after 10 min, I can actually see the picture there.

Comment 51

[Julien Wajsberg [:julienw]]

Bevis: I'll reproduce what I saw and will file another bug
Bingqing: then I couldn't reproduce :( do you have the delivery tick icon on the sending device too?

Comment 52

[Bingqing Li]

(In reply to Julien Wajsberg [:julienw] from comment #51)
> Bingqing: then I couldn't reproduce :( 
I cannot reproduce this issue on build 20140527014007 either, which is really strange. 

> do you have the delivery tick icon on the sending device too?
You mean an icon which stands for the message being sent successfully? No I do not have that on the sending device.

Comment 53

[Julien Wajsberg [:julienw]]

(In reply to Bingqing Li from comment #52)
> (In reply to Julien Wajsberg [:julienw] from comment #51)
> > Bingqing: then I couldn't reproduce :( 
> I cannot reproduce this issue on build 20140527014007 either, which is
> really strange. 
> 
> > do you have the delivery tick icon on the sending device too?
> You mean an icon which stands for the message being sent successfully? No I
> do not have that on the sending device.

Do you have "delivery report" enabled on the sending device?
(I ask because it makes it easier to know when the message has been received by the DuT)

Comment 54

[Bingqing Li]

(In reply to Julien Wajsberg [:julienw] from comment #53)
> Do you have "delivery report" enabled on the sending device?
> (I ask because it makes it easier to know when the message has been received
> by the DuT)

I'm sorry, I used my iPhone as the sending device, and I cannot find "delivery report" option on my iPhone.

Comment 55

[Julien Wajsberg [:julienw]]

Peter, any luck?


Note that I'm away until next monday so you'll need another owner until then.
Anyway I couldn't reproduce so it's maybe a good idea to have another owner...

Comment 56

[Peter Bylenga [:PBylenga]]

We are continuing to do testing to get this right, but so far it appears that using an Iphone as the sending device breaks the notification for that message and any message sent thereafter from other devices (Android, FFOS).  We're also testing to see if there is a solid workaround to start getting notifications again for MMS received from non-Iphone devices.

To clarify, we see a device work with sending MMS from Android and FFOS, then using an Iphone (Same AT&T carrier as the other phones) the notification won't trigger.  We've also tested TMobile carrier but so far Iphone is what is standing out as a key component to getting this bug to reproduce.

Comment 57

[Bingqing Li]

FYI
I cannot reproduce this issue on build 20140528190947 with the latest pac.


Build Info
--------------------------------------------
Gaia      303e375a1b4c721984dcb68dfca24d6f50c291f2
Gecko     https://hg.mozilla.org/releases/mozilla-b2g28_v1_3t/rev/fcabeab5ebec
BuildID   20140528190947
Version   28.1
ro.build.version.incremental=eng.cltbld.20140528.181747
ro.build.date=Wed May 28 18:17:57 EDT 2014

Comment 58

[Peter Bylenga [:PBylenga]]

The results from our testing on:

Environmental Variables:
Device: Tarako
BuildID: 20140527215752
Gaia: 303e375a1b4c721984dcb68dfca24d6f50c291f2
Gecko: e4b8f5bf7ea9
Version: 28.1
Firmware Version: SP6821a-Gonk-4.0-5-12


A phone with 14 notifications unchecked reproduced the bug when sending additional messages with multiple images. 100%  reproduction rate

Issue reproduced when music was played for over 15 minutes. 60% reproduction rate

Iphone 4s MMS does not give a notification 100% reproduction rate

The MMS notification from buri did not come in after the Iphone 4s MMS test 80% reproduction rate

Iphone 3 MMS does not give a notification 100% reproduction rate

The MMS notification from buri did not come in after the Iphone 3 MMS test 80% reproduction rate

Some notifications did not come in after sending many MMSes at in quick sucession one after another (5+) 90% reproduction rate

Comment 59

[Steve Chung [:steveck]]

Take it since julien is PTO now, and Oleg will also help with the investigation.

Comment 60

[Steve Chung [:steveck]]

Quick update based on what I saw on latest build:

All the sms notification works fine, the difference would be sending mms from different os device. I could not reporduce it if the mms is sent from android/ffos, but it always busted if mms is sent from iOS(no matter the mussic is on or not), and cause the message app goes into invalid state and app could not launch or receive notification correctly. The only way to resume is to kill the message app and re-launch again. So I need QA support to clarify that:

1) The root cause is mms sent from iOS and it's always reproducible no matter the music is playing or not.
2) mms sent from other non-iOS works fine
3) Reproducible on v1.4/master ?

Comment 61

[Joe Cheng [:jcheng] (please needinfo)]

MMS from iPhone only seems to make this a less severe problem for the target market. 1.3T?

Comment 62

[Steve Chung [:steveck]]

Attachment: Link to github

Hi Oleg, this should be a regression from bug 995907 since we splited the message receiving page from message app to avoid LMK issue. But Utils.js is missed in this view and cause message without smil(like iOS mms) and subject unable to display the notification correctly because handling these messages will need funciotn from Utils.js.

Comment 63

[Steve Chung [:steveck]]

(In reply to Joe Cheng [:jcheng] from comment #61)
> MMS from iPhone only seems to make this a less severe problem for the target
> market. 1.3T?

I think it's not limited to the iOS issue. Like I said in comment 62, receiving mms without smil and subject will break the notification for sure.

Comment 64

[Jason Smith [:jsmith]]

(In reply to Joe Cheng [:jcheng] from comment #61)
> MMS from iPhone only seems to make this a less severe problem for the target
> market. 1.3T?

I think the data in comment 58 is misleading. It's wording the reproduction rate inconsistently, so I don't think we can compare IPhone to Firefox OS here. So something seems a little bit off here.

I'm going to talk to Peter about this.

Comment 65

[Michael Henretty [:mikehenrty][:mhenretty]]

(In reply to Steve Chung [:steveck] from comment #62)
> Created attachment 8431676 [details] [review]
> Link to github
> 
> Hi Oleg, this should be a regression from bug 995907 since we splited the
> message receiving page from message app to avoid LMK issue. But Utils.js is
> missed in this view and cause message without smil(like iOS mms) and subject
> unable to display the notification correctly because handling these messages
> will need funciotn from Utils.js.

What function from Utils will onSmsReceived need? Based on the behavior described in comment #2, we are running [1] when the SMS app is in the background, which is causing the notification to never get sent. Sounds like we might have multiple issues here.

1.) https://github.com/mozilla-b2g/gaia/blob/e321551f4cf958f039418263e351e672d79ac839/apps/sms/js/activity_handler.js#L373

Comment 66

[Peter Bylenga [:PBylenga]]

(In reply to Steve Chung [:steveck] from comment #60)
> Quick update based on what I saw on latest build:
> 
> All the sms notification works fine, the difference would be sending mms
> from different os device. I could not reporduce it if the mms is sent from
> android/ffos, but it always busted if mms is sent from iOS(no matter the
> mussic is on or not), and cause the message app goes into invalid state and
> app could not launch or receive notification correctly. The only way to
> resume is to kill the message app and re-launch again. So I need QA support
> to clarify that:
> 
> 1) The root cause is mms sent from iOS and it's always reproducible no
> matter the music is playing or not.
> 2) mms sent from other non-iOS works fine
> 3) Reproducible on v1.4/master ?

1) This is correct, in all circumstances sending from iOS failed to trigger a notification.  Even without music/video in foreground.

2) MMS sent from other non-iOS does NOT work as expected under these circumstances with rates (%):
  a) have Multiple notifications pending to be checked, receive a new MMS (60%)
  b) receive multiple MMS (5 were used) in quick succession (90%)
  c) receive an additional MMS after receiving one from an iOS device (80%)

3) working as expected on 1.4 and 2.0/master, flame was checked

Comment 67

[Jason Smith [:jsmith]]

So comment 66 implies this is not specific to an iOS --> Firefox OS communication setup - this can happen with other mobile operating systems. The particular case I'm concerned about is 2a), as that's definitely plausible for a user to hit & 60% is pretty high for reproduction rate. The above comments indicate also that this is a regression as well. So that's leaning me towards keeping this on the blocking list.

Comment 68

[Steve Chung [:steveck]]

(In reply to Michael Henretty [:mhenretty] from comment #65)
> (In reply to Steve Chung [:steveck] from comment #62)
> > Created attachment 8431676 [details] [review]
> > Link to github
> > 
> > Hi Oleg, this should be a regression from bug 995907 since we splited the
> > message receiving page from message app to avoid LMK issue. But Utils.js is
> > missed in this view and cause message without smil(like iOS mms) and subject
> > unable to display the notification correctly because handling these messages
> > will need funciotn from Utils.js.
> 
> What function from Utils will onSmsReceived need? Based on the behavior
> described in comment #2, we are running [1] when the SMS app is in the
> background, which is causing the notification to never get sent. Sounds like
> we might have multiple issues here.
> 
> 1.)
> https://github.com/mozilla-b2g/gaia/blob/
> e321551f4cf958f039418263e351e672d79ac839/apps/sms/js/activity_handler.js#L373

When receiving a mms, we will need to parse the mms for the text content[1]. And it will need an utils function to parse the mms without smil[2]. That's all I found for now because I couldn't reproduce it in other cases. But it still has the possibility that we got other issue here.

[1] https://github.com/mozilla-b2g/gaia/blob/v1.3t/apps/sms/js/activity_handler.js#L415
[2] https://github.com/mozilla-b2g/gaia/blob/v1.3t/apps/sms/js/smil.js#L247

Comment 69

[Julien Wajsberg [:julienw]]

Let's already fix the obvious regression found by Steve as this will make things clearer. I also think there is other issues because the logcat does not show any "Javascript Error" (which it would if we encountered the regression).

Comment 70

[Steve Chung [:steveck]]

Hi Oleg, thanks for the reminder and I just add wbmp.js for sms receiving(and I think this set of js should be safe)

Comment 71

[Oleg Zasypkin [:azasypkin]]

Comment on attachment 8431676 [details] [review]
Link to github

(In reply to Steve Chung [:steveck] from comment #70)
> Hi Oleg, thanks for the reminder and I just add wbmp.js for sms
> receiving(and I think this set of js should be safe)

Thanks, Steve! r=me

Comment 72

[Steve Chung [:steveck]]

in v1.3T : fe4b20403e6fee8b54a69aa872bfb35cbc9af651

I'll try to verify if intermittent notification missing issue still happen after landing this patch.

Comment 73

[Julien Wajsberg [:julienw]]

Can we test this again with a build that contains the commit fe4b20403e6fee8b54a69aa872bfb35cbc9af651 ?

Comment 74

[bhavana bajaj [:bajaj]]

Adding NO_UPLIFT until QA/Steve have verified the issue on a tarako. NAoki, anyway you can apply this patch and help with verification here ?

Comment 75

[Steve Chung [:steveck]]

I could not reproduce it on device with 5/28 build including with my patch. The notification works fine even I stack up more than 10 messages(some of messages are mms), and the music is playing for 10 mins around. Please note that only 2 apps(music and message) are opened during my testing, and I didn't play it for long period of time(less than few hours).

Comment 76

[Jason Smith [:jsmith]]

No uplift isn't going to do squat here - the patch is already uplifted per comment 72.

Comment 77

[Julien Wajsberg [:julienw]]

We didn't want to set any flag to "fixed" because the patch should not solve all things that have been said here.

That's why it would be nice if QA could try to reproduce this again before marking this as fixed.

Alternatively, we can mark this fixed and file another bug if necessary.

Comment 78

[Naoki Hirata :nhirata (please use needinfo instead of cc)]

bug 1002897 probably helped.  It landed 6/3, it should be in 6/4 build.

Comment 79

[Naoki Hirata :nhirata (please use needinfo instead of cc)]

I tested with getting MMS on Sim1, and Sim2 with music in the foreground and also with music in the background, as well as music in the background with settings app in the foreground.

I could not reproduce the issue.  I got a notification each time.

Note: SIM data is needed to actually have the download downloaded, it does matter which sim is turned on for that to download the whole message.

Gaia      33025a8b1e458ef48cb8b7fb81bdaba28c86b183
Gecko     https://hg.mozilla.org/releases/mozilla-b2g28_v1_3t/rev/161d4b0448c6
BuildID   20140606014002
Version   28.1
ro.build.version.incremental=eng.cltbld.20140606.050809
ro.build.date=Fri Jun  6 05:08:16 EDT 2014
Tarako

Comment 80

[Naoki Hirata :nhirata (please use needinfo instead of cc)]

To note, I ran into bug 976089; I think it would also be nice to have a 1 or 2 indicator in the notification to show at a glance which SIM received the MMS without having to go to the SMS app.

Notification doesn't seem to occur if you don't have data to that SIM.
ie if the SIM data is going to SIM 1, and you send a MMS to SIM 2, the notification will not show at all.  In SMS you will see a message of "I have sent you a file. It will be available until <date>."

I'm not sure if these case are expected or not.  I think if they are not, then it might be better to create new bugs for these specific issues?

Comment 81

[Julien Wajsberg [:julienw]]

The "SIM in notification" bug is not bug 976089, it's bug 947180 (fixed in v1.4).

The fact that there is no notification in that case could be a real bug though. Keeping the NI to investigate next week.

Comment 82

[Julien Wajsberg [:julienw]]

Naoki, I don't see the issue you're saying about the notification not showing, neither on v1.3t nor on master. Can you share a STR with me (possibly filing a separate bug)?

Comment 83

[Naoki Hirata :nhirata (please use needinfo instead of cc)]

Thanks Julien, I will retest to double verify and possibly file a new bug.

Comment 84

[Naoki Hirata :nhirata (please use needinfo instead of cc)]

I could not hit the bug in today's build.  No other bug will be reported.

Comment 85

[Wei Gao (Spreadtrum)]

Hi Steve

I am sorry to say this bug is still exist.
I grabed log, and found the "navigator.mozApps.getSelf().onsuccess" had been registered, but the code in it was not be excuted all the time, when keep playing music at foreground.
Can you help to check it?

https://github.com/mozilla-b2g/gaia/blob/v1.3t/apps/sms/js/activity_handler.js#L381-L450

Comment 86

[Wei Gao (Spreadtrum)]

Hi Julien

Please help to verify it.
Thanks a lot.

Comment 87

[Steve Chung [:steveck]]

(In reply to wei.gao from comment #85)
> Hi Steve
> 
> I am sorry to say this bug is still exist.
> I grabed log, and found the "navigator.mozApps.getSelf().onsuccess" had been
> registered, but the code in it was not be excuted all the time, when keep
> playing music at foreground.
> Can you help to check it?
> 
> https://github.com/mozilla-b2g/gaia/blob/v1.3t/apps/sms/js/activity_handler.
> js#L381-L450

Could you please provide more details about your build and the reproduce step/rate? Since our QA alreaady reported that this issue didn't exist(comment 84) and I couldn't reproduce it either, it would be great if you can log more information about:
1) dispatchNotification did called when message received 
2) navigator.mozApps.getSelf().onsuccess registered
3) Any low memory kill from the log if onsuccess isn't triggered
4) Register navigator.mozApps.getSelf().onerror for more error information

BTW, please note that Julien is out till 6/30, thanks!

Comment 88

[Wei Gao (Spreadtrum)]

(In reply to Steve Chung [:steveck] from comment #87)
> BTW, please note that Julien is out till 6/30, thanks!
I am sorry to trouble Julien, sorry.

> Could you please provide more details about your build and the reproduce
> step/rate? Since our QA alreaady reported that this issue didn't
> exist(comment 84) and I couldn't reproduce it either, it would be great if
> you can log more information about:
> 1) dispatchNotification did called when message received 
> 2) navigator.mozApps.getSelf().onsuccess registered
> 3) Any low memory kill from the log if onsuccess isn't triggered
> 4) Register navigator.mozApps.getSelf().onerror for more error information

Hi Steve

My reproduce steps:
1、send a mms to myself.
2、open music app and play a music.
3、wait for notification from message.
4、there is nothing happened and no notification.
5、open sms app, and find the mms has been received a few minutes ago.

I register navigator.mozApps.getSelf().onerror and add some log in it.
After my operation, there is only '-->mozApps' in log.
Besides that, I do not find OomLogger and adj in main.log
@@ -377,7 +377,12 @@ var ActivityHandler = {
         }
       }

+      console.log('-->mozApps');
+      navigator.mozApps.getSelf().onerror = function(evt) {
+        console.log('-->mozApps_onerror');
+      }
       navigator.mozApps.getSelf().onsuccess = function(evt) {
+        console.log('-->mozApps_onsuccess');
         var app = evt.target.result;
         var iconURL = NotificationHelper.getIconURI(app);

Thanks.

Comment 89

[James Zhang (Spreadtrum)]

Reopen because we met this issue again.

Comment 90

[Julien Wajsberg [:julienw]]

could be bug 994079 somehow ?

Comment 91

[Steve Chung [:steveck]]

(In reply to Julien Wajsberg [:julienw] (away June 21 to 30) from comment #90)
> could be bug 994079 somehow ?

It seems confirmed in bug 1026737 comment 22.

Hi James, please nominate bug 1026737 as 1.3T blocker if this issue still exists, thanks.

Comment 92

[ying.xu]

(In reply to Julien Wajsberg [:julienw] (away June 21 to 30) from comment #90)
> could be bug 994079 somehow ?

I applied patch from bug 994079 and test again
still no any notification

Comment 93

[James Zhang (Spreadtrum)]

Ying, try bug 1026737.

Comment 94

[ying.xu]

I did more tests with and without patch from bug 1026737
But I can't get consistent results.

I received the notification without the patch sometimes
and I didn't receive the notification with the patch sometimes.

Comment 95

[Steve Chung [:steveck]]

Hi wei,
Could you still reproduce the problem you mentioned in comment 88 after applying the patch in bug 1026737?

Comment 96

[Wei Gao (Spreadtrum)]

(In reply to Steve Chung [:steveck] from comment #95)
> Hi wei,
> Could you still reproduce the problem you mentioned in comment 88 after
> applying the patch in bug 1026737?

Hi Steve

I apply the patch in bug1026737 and rebuild gecko, but this bug can still be reproduced through comment 88.

Comment 97

[Wei Gao (Spreadtrum)]

(In reply to Steve Chung [:steveck] from comment #95)
> Hi wei,
> Could you still reproduce the problem you mentioned in comment 88 after
> applying the patch in bug 1026737?

After testing the patch, I think the reason is as same as the comment 88.
I grab the log and find the 'navigator.mozApps.getSelf().onsuccess' which is registered in 'function dispatchNotification(needManualRetrieve)' is still not be entered.

Please help to check it.
Thanks.

Comment 98

[Steve Chung [:steveck]]

Since I still could not reproduce on the latest tarako build, I will ni? Oleg and QA for more investigation.

Comment 99

[Steve Chung [:steveck]]

Hi Oleg, could you help with this issue(if you could reproduce it)?

Comment 100

[Oleg Zasypkin [:azasypkin]]

(In reply to Steve Chung [:steveck] from comment #99)
> Hi Oleg, could you help with this issue(if you could reproduce it)?

Sure, I'm trying to repro this at the moment, so keeping ni=me for now.

Comment 101

[Harvey]

I was able to reproduce this issue today using the latest Tarako build though it was intermittent, the repro rate for me was around a third of the time.

Environmental Variables:
Device: Tarako 1.3T
Build ID: 20140624163406
Gaia: 8b706d131a002397076eccfaa47b7752a0792496
Gecko: 8b11967e5b38
Version: 28.1 (1.3T)
Firmware Version: SP6821a-Gonk-4.0-5-12

Comment 102

[Oleg Zasypkin [:azasypkin]]

I was able to find a way of reproducing it pretty frequently. For my case it doesn't matter whether it's MMS or SMS. What seems is matter is that I have Music app in background and once I send message from SIM2 to SIM1 I slide down notification panel, tap on "Play" button (at music controls displayed in the notification panel) and then switch to Music app by tap on song album icon. I can't reproduce it if I switch to Music app via card view.

I see only these two messages (that look suspicious) in the logcat output(adb logcat | grep Gecko):
"###!!! [Parent][MessageChannel] Error: Channel error: cannot send/recv"
"###!!! [Child][OnMaybeDequeueOne] Error: Channel closing: too late to send/recv, messages will be lost"

It seems ActivityHandler isn't even activated in this case. But once I send message and don't switch to Music app, logcat shows a bunch of calls to "ActivityHandler.dispatchNotification\navigator.mozApps.getSelf()" (number of calls equals to number of previously missed notifications) and "navigator.mozApps.getSelf().onsuccess" is called only once and shows only one notification usually about the first missed message in a row.

I will investigate it further tomorow.

Hi Wei, could you please clarify two things:
* How exactly do you switch to the Music app once you send a message to yourself?
* Can you reproduce this issue for SMS?

Thanks!

Comment 103

[Wei Gao (Spreadtrum)]

(In reply to Oleg Zasypkin [:azasypkin] from comment #102)
> Hi Wei, could you please clarify two things:
> * How exactly do you switch to the Music app once you send a message to
> yourself?
> * Can you reproduce this issue for SMS?

Hi Oleg

I just send a message to myself, then close sms app and then open music app quickly. I think that doesn't matter. 
I use another phone to send a mms to my test phone just now, this bug can still be reproduced.

But the sms notification function is normal. No matter what I did, there will be notification and a bell received.

Thanks.

Comment 104

[Wayne Chang [:wchang]]

Clarified with the partner here, the issue now seem to appear when the device is sending a message to itself.

So note:
1) the user impact of this bug then becomes relatively low
2) it might be due to a different cause then the original bug

Comment 105

[ying.xu]

(In reply to Julien Wajsberg [:julienw] (away June 21 to 30) from comment #90)
> could be bug 994079 somehow ?

I finally confirmed the bug994079 can fix one aspect of this bug.I don't know if there were others.
I added one more call to navigator.mozApps.getSelf() before the original one.
After done this, without patch of bug994079.

the bug can be reproduced with 100% possibilites, no matter sms or mms.
I/GeckoDump( 1644): gaia sms ActivityHandler onSmsReceived message class = normal
I/GeckoDump( 1644): gaia sms ActivityHandler onSmsReceived message type = sms
I/GeckoDump( 1644): gaia sms ActivityHandler dispatchNotification mozApps.getSelf 1st app = app://sms.gaiamobile.org
I/GeckoDump( 1644): gaia sms ActivityHandler onSmsReceived message class = normal
I/GeckoDump( 1644): gaia sms ActivityHandler onSmsReceived message type = sms
I/GeckoDump( 1644): gaia sms ActivityHandler dispatchNotification mozApps.getSelf 1st app = app://sms.gaiamobile.org

and with patch of bug994079, the notification can be displayed.
I/GeckoDump( 2017): gaia sms ActivityHandler onSmsReceived message class = normal
I/GeckoDump( 2017): gaia sms ActivityHandler onSmsReceived message type = sms
I/GeckoDump( 2017): gaia sms ActivityHandler dispatchNotification mozApps.getSelf 1st app = app://sms.gaiamobile.org
I/GeckoDump( 2017): gaia sms ActivityHandler dispatchNotification mozApps.getSelf 2nd app = app://sms.gaiamobile.org

Comment 106

[ying.xu]

Attachment: getself.patch

my patch to reproduce this bug

Comment 107

[Rachelle Yang [:ryang][[e-mail]]]

Hi Ying, 

Thanks for your update. 

Based on your comment105 and comment106, May I conclude that with the patch in comment106(which  is the same patch for bug994079), the issue of MMS&SMS not displaying notification while playing music is completely gone.
Is that correct? Thanks !

Comment 108

[ying.xu]

(In reply to Rachelle Yang [:ryang][[e-mail]] from comment #107)

> Based on your comment105 and comment106, May I conclude that with the patch
> in comment106(which  is the same patch for bug994079), the issue of MMS&SMS
> not displaying notification while playing music is completely gone.
> Is that correct? Thanks !

I'm not sure. I suspect there ware other reasons leading to this bug.
I'm still waiting for the bug reproduced from sprd QA. let's keep it open and watch it for some time

Comment 109

[Julien Wajsberg [:julienw]]

Ying, I'm gonna close this bug because a patch has landed here already.

Please file a separate bug if you still encounter a similar issue, as it will make it easier to track the different commits.

Comment 110

[James Zhang (Spreadtrum)]

Ying, please file a new bug to track, thank you.

Comment 111

[Keven Kuo [:kkuo]]

Hi! Ying,

Please file a new bug and update the bug number here.
Thanks

--
Keven

Comment 112

[ying.xu]

clone a new bug