859743 - SMS not received while browsing

Status: RESOLVED DUPLICATE of bug 860799

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

Description

[Juan Perez-Bedmar [:juanpbf]]

Buildid "20130321070205", ikura.

SMS are not received while a web page is loading. It's necessary to wait until the web page is fully loaded to receive the SMS.

This has been reported by Telefonica Spain during the certification process as follows:

--------------------------------------------------------------

Testing procedure is:
1. Open the internet browser.
2. Load an URL (for instance  www.publico.es)
3. While the web page is loading, from another handset send a SMS to the DuT

Expected result:
The SMS should be received although the web page is loading.

Current result
The sms is not received until de web page is loaded. Sometimes even later.
--------------------------------------------------------------

My impression is that the SMS DOES arrive, but the user is not notified. It could be an issue more related to notifications. 

I have reproduced this issue, and sometimes the notification doesn't arrives until I open the SMS application directly.

Logs has been requested to Telefonica Spain. Will be added here when provided.

Marked as P1, since it's a blocker for Telefonica Spain certification process

Comment 1

[Juan Perez-Bedmar [:juanpbf]]

Dependency with Telefonica Spain certification process [meta] added.

Comment 2

[David Palomino [:dpalomino]]

Hi, 

This is a blocking issue, nominating tef?

Thks!
David

Comment 3

[Daniel Coloma:dcoloma]

Dale, could this be somehow related to bug 845661?

Comment 4

[Dale Harvey (:daleharvey)]

It looks very likely, will block on it and remember to test

Comment 5

[Kai-Chih Hu [:khu]]

Ken, could you help to take a look on this case? Thanks!

Comment 6

[Kai-Chih Hu [:khu]]

Talked with Ken, it would be better to have logs for analysis. 
Marked it as "qawanted".

Comment 7

[Ken Chang[:kenkai]]

Patrick, it seems that process is fully running the browser function. please look into this bug.

Comment 8

[David Palomino [:dpalomino]]

Hi, 

This is not happening now, not confirmed to be a device issue. I suggest to mark the bug as resolved/worksforme and reopen it if appears again. 

Thanks!
David

Comment 9

[Ken Chang[:kenkai]]

According to the comment 8, change the bug state.

Comment 10

[Patrick Wang (Chih-Kai Wang) (:kk1fff)]

This doesn't always happen, but it happens when browsing complex page. My observation is that when SMS arriving, system message tries to open sms app and send system message to sms app, but the sms app is killed because of OOM before it can handle the system message.

Comment 11

[Daniel Coloma:dcoloma]

(In reply to Patrick Wang [:kk1fff] from comment #10)
> This doesn't always happen, but it happens when browsing complex page. My
> observation is that when SMS arriving, system message tries to open sms app
> and send system message to sms app, but the sms app is killed because of OOM
> before it can handle the system message.

Based on this comment, I think it might be related with bug 847592.

Justin, do you think both issues are related?

Comment 12

[Justin Lebar (not reading bugmail)]

> My observation is that when SMS arriving, system message tries to open sms app and send system 
> message to sms app, but the sms app is killed because of OOM before it can handle the system message.

To be clear, you verified that the SMS app is actually killed by OOM by looking at dmseg?

Gaia probably doesn't give the SMS app mozapptype=critical.  Without this, apps that are expecting system messages can get OOMed by the foreground app.  This stands in contrast to the communications app, which (usually) doesn't get OOMed by the foreground app.

We walk a fine line here.  Some process has to have a higher priority than the other one.  If you give the SMS app mozapptype=critical, receiving an SMS can kill whatever app you're using.  OTOH if you give the app higher priority, you can miss an SMS.

What I think we may need a notion of "please retry delivering this system message again," but that becomes pretty complex, especially since system messages are not idempotent.

Comment 13

[Patrick Wang (Chih-Kai Wang) (:kk1fff)]

(In reply to Justin Lebar [:jlebar] from comment #12)
> 
> To be clear, you verified that the SMS app is actually killed by OOM by
> looking at dmseg?
> 

I saw these in dmesg:
<4>[04-11 11:47:07.112] [28: kswapd0]select 2765 (Messages), adj 6, size 4970, to kill
<4>[04-11 11:47:07.112] [28: kswapd0]send sigkill to 2765 (Messages), adj 6, size 4970

Comment 14

[Justin Lebar (not reading bugmail)]

I guess it's wrong that the SMS frame gets a priority equal to the other background processes.  We could give it either background_perceivable priority, or a new priority in-between background_perceivable and background.  Then receiving an SMS could kill a non-perceivable background process, which is probably what you want.

I'll file a bug.

Comment 15

[Justin Lebar (not reading bugmail)]

I filed bug 860799 on this.

Comment 16

[Cody Roesch [:croesch]]

Unagi Build: 20130411070205
Kernel: Dec 5th
Gecko  http://hg.mozilla.org/releases/mozilla-b2g18/rev/f671fa539473
Gaia   e7e338a765e22334b40ced41489a785941382c66

In the above build, I too see the issue with no receiving SMS messages while loading a webpage. In my test I loaded a content heavy website www.Gamespot.com. While loading I sent a sms message to the device and waited. Even after the website finished loading there was no SMS message. Only one i opened the Messaging app did I get notified. Attached is the log file from the time I started loading and sent the message till the website finished loading and was waiting for the Text to appear.

Comment 17

[Cody Roesch [:croesch]]

Attachment: Log

Comment 18

[Justin Lebar (not reading bugmail)]

Comment on attachment 736367 [details]
Log

We need the dmesg log, which is not the same as the logcat log.

Comment 19

[Ken Chang[:kenkai]]

It is happened again. See comment 16. Reopen it.