Closed Bug 904470 Opened 9 years ago Closed 9 years ago

[Buri][SMS]The message list will disappear when receive a Class0 message

Categories

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

defect

Tracking

(blocking-b2g:leo+, b2g18 fixed, b2g-v1.1hd fixed)

RESOLVED FIXED
blocking-b2g leo+
Tracking Status
b2g18 --- fixed
b2g-v1.1hd --- fixed

People

(Reporter: sync-1, Assigned: alive)

References

Details

(Keywords: regression, Whiteboard: [com_ril] QARegressExclude)

Attachments

(3 files)

AU_LINUX_GECKO_ICS_STRAWBERRY.01.01.00.019.184
 Firefox os  v1.1
 Mozilla build ID:20130806071254
 Created an attachment (id=484793)
 0809
 
 DEFECT DESCRIPTION:
 The message list will disappear when receive a Class0 message
 
 REPRODUCING PROCEDURES:
 Precondition:
 Have no the number of you will receive in message list.
 
 1.Enter SMS app,then press home key to clear the SMS record.
 2.Press power key to lock screen.
 3.Receive a Class 0 message,unlock screen.
 4.Enter SMS app,find the message list disappear. --KO
 
 EXPECTED BEHAVIOUR:
 The message list will not disappear when receive a Class0 message
 
 
 ASSOCIATE SPECIFICATION:
 
 TEST PLAN REFERENCE:
 
 TOOLS AND PLATFORMS USED:
 
 USER IMPACT:
 Medium
 
 REPRODUCING RATE:
 5/5
 
 For FT PR, Please list reference mobile's behavior:
Clone from brother
Attached file 504542-logcat
Clone from brother
blocking-b2g: --- → leo?
Class-0 message is not saved in database. See 3GPP 23.038 chapter 4 "SMS Data Coding Scheme":

  When a mobile terminated message is class 0 and the MS has the capability of
  displaying short messages, ... The message shall not be automatically stored
  in the (U)SIM or ME.
Status: NEW → RESOLVED
Closed: 9 years ago
Resolution: --- → INVALID
blocking-b2g: leo? → ---
Dear Vicamo Yang,
I think you misunderstand my defect description. I didn't mean that class-0 message is not storage in database. I meant class-0 message will block the display of message list and will cause no messages at all.
Did you follow my steps and reproduce this pr?
Did you see the attachment?
I am looking forward to your reply.
BRs,
TIAN Min
Flags: needinfo?(vyang)
First, that log is for commercial RIL.  It sounds you're describing a Gaia bug, not a Gecko one. So I just revert the changes I made, but note that if you really mean this is a Gecko side bug, you'd either create an issue in commercial RIL bug tracker or resolve this again as INVALID because Mozilla RIL will not save Class-0 messages in database.  Thank you for the clarification.
Status: RESOLVED → REOPENED
blocking-b2g: --- → leo?
Flags: needinfo?(vyang)
Resolution: INVALID → ---
Whiteboard: [com_ril]
qawanted to confirm the bug
Keywords: qawanted
(In reply to Joe Cheng [:jcheng] from comment #7)
> qawanted to confirm the bug

We don't have the ability to test class-0 messages on Mozilla's side.

David - Are you able to ask the test lab to help confirm this bug?
Flags: needinfo?(dpv)
(In reply to Jason Smith [:jsmith] from comment #8)
> (In reply to Joe Cheng [:jcheng] from comment #7)
> > qawanted to confirm the bug
> 
> We don't have the ability to test class-0 messages on Mozilla's side.

Actually, we do, with emulator:

  $ ./run-emulator.sh &
  $ telnet localhost 5554
  > sms pdu 00000191F10010001010000000000141
  OK

See https://mxr.mozilla.org/mozilla-central/source/dom/mobilemessage/tests/marionette/test_message_classes.js#57
Ah, didn't know that. Okay, we'll test this with the emulator then.
Flags: needinfo?(dpv)
(In reply to Jason Smith [:jsmith] from comment #10)
> Ah, didn't know that. Okay, we'll test this with the emulator then.

I wanted to help yesterday, but somehow homescreen never showed up in emulator in my local build. Don't know why yet.
Whiteboard: [com_ril] → [com_ril] QARegressExclude
Triage decision was that this is likely a regression from v1.0.1 and if class 0 messages cause the entire list to disappear that's definitely a blocker.
blocking-b2g: leo? → leo+
Keywords: regression
So, I've tried testing this using a setTimeout to fake a class-0 message, and I can't seem to reproduce it.

Questions about the STR though:

When I hit "home" to go back to the home screen, am I looking at the Thread List, or a specific thread?  I tried both and neither one results in an empty list.
(In reply to Corey Frang [:gnarf] [:gnarf37] from comment #13)
> So, I've tried testing this using a setTimeout to fake a class-0 message,
> and I can't seem to reproduce it.
> 
> Questions about the STR though:
> 
> When I hit "home" to go back to the home screen, am I looking at the Thread
> List, or a specific thread?  I tried both and neither one results in an
> empty list.
You should kill the sms app first. Then when you receive a class-0 message, this message will block the display of the message list.
ah, this reminds me a very old bug, but I can't find it.

田旻, is there any logcat log ?
Flags: needinfo?(tianm)
(In reply to Julien Wajsberg [:julienw] from comment #15)
> ah, this reminds me a very old bug, but I can't find it.
> 
> 田旻, is there any logcat log ?
I have already uploaded some logcat log at the very beginning.
Flags: needinfo?(tianm)
Right, thanks a
Right, thanks a lot.

Strangely I don't see any messages from the application, especially no JavaScript Error. I don't exactly know if we need to enable anything to see those JavaScript Errors, maybe the Console in the advanced Settings ?
We display class-0 messages using a modal "window.alert". We had other bugs because of this already, because we don't receive any events anymore while we have this. Moreover, the events are just discarded, not buffered.

Therefore I wonder if the problem is not because of this (just guessing here). I'll try to build an emulator for the first time to try this...
Assignee: nobody → felash
So, bug 903260 was incorrectly on v1-train which triggered another bug which was preventing us from seeing this bug. Now that I reverted that bug, I can see this bug.

However therefore I'm a bit worried: if you had this bug, does this mean you don't have all v1-train on your end ?
Here is the exact bug I see :

* the Sms app needs to not run, but it doesn't matter whether the phone is locked
* receive a class-0 message
* the sms app launches automatically, and stays blank as comment 0 says

However then I can do the following :

* press home
* launch the sms app again
=> now I see the class-0 message, and when I press ok everything loads as expected

Tianm, can you confirm that you have the same behavior ? It would help knowing that we see the same problem.
Flags: needinfo?(tianm)
The code is exactly the same whether the app was not running or the app was just put in the background by the user.

Therefore I'd say there is a race condition in the system app, between launching the app and showing an alert. Also, this works if I flash the master version of the System app only on a v1.1 device.

Therefore I'm moving component and I'll try to find if an existing fix would need an uplift.
Component: Gaia::SMS → Gaia::System
moving forward: we don't get the mozbrowserloadend event on the launched iframe.
Duplicate of this bug: 905052
very strangely everything seems to work as expected when I try the deleted message use case from bug 837029 which also does an alert after a system message.

The only difference between both use cases is that with the class-0 use case (this bug) we call app.launch and then alert, whereas with the notification use case (bug 837029) we call app.launch, then we have an asynchronous call, and only then we call window.alert. Therefore the asynchronous call might give some time to the engine to do something.
Ok, we don't get the mozbrowserloadend/appopen events either in the notification use case, but the asynchronous call probably let the app launch correctly, and the system's modal_dialog.js logic probably sees the app as being currently displayed.

so here is a possible workaround: do the alert inside a setTimeout.
This is a patch that adds console.log calls in interesting areas.

This applies on v1-train.
Alive, I would value your help here, as I am a little bit lost and I don't know how to move forward with this. Maybe the big window_manager change on master fixed this incidentally, but I can't see how.

I think you can reproduce easily with my logs without using the emulator; merely executing a system message should trigger this.
Flags: needinfo?(alive)
(In reply to Julien Wajsberg [:julienw] from comment #21)
> Here is the exact bug I see :
> 
> * the Sms app needs to not run, but it doesn't matter whether the phone is
> locked
> * receive a class-0 message
> * the sms app launches automatically, and stays blank as comment 0 says
> 
> However then I can do the following :
> 
> * press home
> * launch the sms app again
> => now I see the class-0 message, and when I press ok everything loads as
> expected
> 
> Tianm, can you confirm that you have the same behavior ? It would help
> knowing that we see the same problem.

Yes, we have the same behavior.
Flags: needinfo?(tianm)
Flags: needinfo?(alive)
(In reply to Julien Wajsberg [:julienw] from comment #28)
> Alive, I would value your help here, as I am a little bit lost and I don't
> know how to move forward with this. Maybe the big window_manager change on
> master fixed this incidentally, but I can't see how.
> 
> I think you can reproduce easily with my logs without using the emulator;
> merely executing a system message should trigger this.

What you are talking about is exactly https://bugzilla.mozilla.org/show_bug.cgi?id=905052#c8, c9, 12

But in the bug isn't the problem is "the message list disappear?"
OK, I think "the message list disappear" implies "no class-0 message is prompted"...
Assignee: felash → alive
Copied from c9 in bug 905252:

The appopen event is expected to be fired once the loading of the app is ended if its never launched and painted.
However, the SMS app is launched in background by System Message handler in Window Manager -> Set the iframe bo be unpainted.

But there's a gap between loadend and firstpaint event of the sms is too late so when it's launched by itself, Window Manager is still waiting for the mozbrowserloadend event, but sms is already loaded.

The key point is sms is loaded in background already, but because of its visibility is hidde, the firstpaint event won't occur before it's brought to foreground.

A quick solution is use mozbrowserloadend event here, but honestly it's still unreliable but we don't have other choice now for v1-train.
Attachment #794433 - Flags: review?(timdream)
Attachment #794433 - Flags: review?(timdream) → review+
v1-train
https://github.com/mozilla-b2g/gaia/commit/3da369c9015b3c7e3798c68146dc94857e78b1e3

NOTE:
This doesn't occur in master. Please don't uplift to master.
Status: REOPENED → RESOLVED
Closed: 9 years ago9 years ago
Resolution: --- → FIXED
v1.1.0hd: 3da369c9015b3c7e3798c68146dc94857e78b1e3
v1.1.0hd: 767499e94db84f91cb07d21872894953cbaae667
Wow, that was quick, thanks a lot alive and tim !
Keywords: qawanted
Dear  Tim Guan-tin Chien,
But on my phone, class-0 message can't be received any more. We can't see any response after we send a class-0 message.
BRs,
TIAN Min
Please give gaia commit info.
(In reply to Alive Kuo [:alive] from comment #38)
> Please give gaia commit info.

Do you mean log files? What is gaia commit info?
Flags: needinfo?
Flags: needinfo?
(In reply to 田旻 from comment #39)
> (In reply to Alive Kuo [:alive] from comment #38)
> > Please give gaia commit info.
> 
> Do you mean log files? What is gaia commit info?

No.

https://github.com/mozilla-b2g/gaia/commit/3da369c9015b3c7e3798c68146dc94857e78b1e3

Uh, do you know what is version control? How do you get your build?
Dears,
This afternoon I test on the newest build (20130826041201), and then it works well.
Thanks very much for your work.
BRs,
TIAN Min
You need to log in before you can comment on or make changes to this bug.