Closed Bug 1119640 Opened 6 years ago Closed 6 years ago

[FFOS2.0][Woodduck][STK]Setup Event executed not ok:Location status Event.

Categories

(Firefox OS Graveyard :: General, defect, P1)

ARM
All
defect

Tracking

(blocking-b2g:2.0M+, b2g-v2.0M fixed, b2g-v2.1 fixed, b2g-v2.1S fixed, b2g-v2.2 fixed, b2g-master fixed)

RESOLVED FIXED
2.2 S4 (23jan)
blocking-b2g 2.0M+
Tracking Status
b2g-v2.0M --- fixed
b2g-v2.1 --- fixed
b2g-v2.1S --- fixed
b2g-v2.2 --- fixed
b2g-master --- fixed

People

(Reporter: pengfei.huang.hz, Assigned: selee)

References

Details

Attachments

(3 files)

Dear Sean Lee & Josh,
  Our VAL guy(another tester) find a strange performance on test version. There are two same envelops(EVENT DOWNLAOD) when event(MT call, Call connected, Call disconnected) received. The wrong envelop come out when we click confirm button of DISPLAY TEXT dialog.  
  Besides, he add a test about LOCATION STATUS. When network(mcc or mnc) change, receive three envelops(EVENT DOWNLOAD). The location event belong to EVENT DOWNLOAD.
  Need your help again. Many thanks. :)
Hi all,
  This bug was fix at bug1088611, see comment41.Thanks.
Hello Pengfei,

I will start the review process.
Thanks for your help.
Attached file PR for master
Hello Fernando,

Here is my PR for this bug. Please help to review it. Thank you.
Attachment #8546420 - Flags: review?(frsela)
blocking-b2g: --- → 2.0M+
See Also: → 1088611
Comment on attachment 8546420 [details] [review]
PR for master

LGTM. Thank you for taking this :)
Attachment #8546420 - Flags: review?(frsela) → review+
Comment on attachment 8546420 [details] [review]
PR for master

[Approval Request Comment]
[Bug caused by] (feature/regressing bug #):
[User impact] if declined:
The behavior of following STK setup events are incorrect.
STK_EVENT_TYPE_LOCATION_STATUS
STK_EVENT_TYPE_IDLE_SCREEN_AVAILABLE
STK_EVENT_TYPE_BROWSER_TERMINATION

Telecom carrier will not accept this if we do not fix it.

[Testing completed]:
Partner tested in their LAB.

[Risk to taking this patch] (and alternatives if risky):
The code change is only for STK and very minor.

[String changes made]:
None
Attachment #8546420 - Flags: approval-gaia-v2.2?
Attachment #8546420 - Flags: approval-gaia-v2.1?
Attachment #8546420 - Flags: approval-gaia-v2.2?
Attachment #8546420 - Flags: approval-gaia-v2.2+
Attachment #8546420 - Flags: approval-gaia-v2.1?
Attachment #8546420 - Flags: approval-gaia-v2.1+
Sean:

As the protocol says "As a result of sending this command to the SIM, the ME shall remove the idle screen available event from its current event list. This is in order for the ME to report this event only once after the event has been requested bythe SIM." 

So the event listener for IDLE_SCREEN_AVAILABLE should be removed once the event happened. But as your modify,the listener can only be removed when we receive another EVENT LIST command.

What do you think about this?
Flags: needinfo?(selee)
And besides, I think your patch is want to remove the event listener when receive new EVENT LIST command. But when I test the case STK_EVENT_TYPE_IDLE_SCREEN_AVAILABLE in v2.1, I found the patch you merged seems do not work. And if we receive two EVENT LIST command of STK_EVENT_TYPE_IDLE_SCREEN_AVAILABLE, when the event happens, we still receive two same envelops(EVENT DOWNLAOD).

What do you think about this?
I create a new bug 1132363 to discuss the implementation of IDLE_SCREEN_AVAILABLE.
Flags: needinfo?(selee)
Hi Jinghua,

Sorry to interrupt this discussion.
Let's move to bug 1132363 and focus on the implementation of IDLE_SCREEN_AVAILABLE .
You need to log in before you can comment on or make changes to this bug.