Closed Bug 1106956 Opened 7 years ago Closed 7 years ago

[FFOS2.0][Woodduck][STK]The idle text can't be removed after power off and on.

Categories

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

defect

Tracking

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

RESOLVED FIXED
blocking-b2g 2.0M+
Tracking Status
b2g-v2.0 --- affected
b2g-v2.0M --- fixed
b2g-v2.1 --- affected
b2g-v2.2 --- fixed

People

(Reporter: sync-1, Assigned: selee)

References

Details

Attachments

(11 files)

email:pengfei.huang.hz.com
 tel:+86-151 1324 9081
 DEFECT DESCRIPTION:
 The idle text can't be removed after power off and on.
 
  REPRODUCING PROCEDURES:
 1.power on with SIM card which can send "set up idle text" command.
 2.Enter settings->STK menu->excute STM12006--Remove “Idle Text” by OFF/ON from handset
 3.power off and on
 4.check the text still in the state bar.--KO
 
  EXPECTED BEHAVIOUR:
 The idle text should be removed after power off and on.
 
 reporter's office number:0752-2639219(61219)
 
  ASSOCIATE SPECIFICATION:
 
  TEST PLAN REFERENCE:
 
  TOOLS AND PLATFORMS USED:
 
  USER IMPACT:
 
  REPRODUCING RATE:
 
  For FT PR, Please list reference mobile's behavior:
Attached file not ok mtklog
Attached file O7G18080AZ00.db
Dear mozilla,
    This bug is related to bug 1106449[FFOS2.0][Woodduck][STK]The idle text was removed after excuting REFRESH-FCN.
    How could we listen the device power off or power on at gaia? If could ,we can remove the idle text.
    it's very nice of you to give us a better suggestion.
    Thanks.
Hi Sean,
Could you please help to check the problem? Thanks!
blocking-b2g: --- → 2.0M?
Flags: needinfo?(selee)
Assignee: nobody → selee
Flags: needinfo?(selee)
Blocks: Woodduck_P2
Notes:
[<<SIM] commandNumber = 1 typeOfCommand = 28 commandQualifier = 0
[<<SIM] Received message from worker: {"commandNumber":1,"typeOfCommand":40,"commandQualifier":0,"rilMessageType":"stkcommand","options":{"text":"IdleText #1"},"rilMessageClientId":0}

[TR]    Received chrome message {"resultCode":0,"command":{"commandNumber":1,"typeOfCommand":40,"commandQualifier":0,"rilMessageType":"stkcommand","options":{"text":"IdleText #1"},"rilMessageClientId":0},"rilMessageClientId":0,"rilMessageToken":19,"rilMessageType":"sendStkTerminalResponse"}

[>>SIM] Received message from worker: {"rilMessageType":"stksessionend","rilMessageClientId":0}
Hi Sean,
This is urgent bug. Please help to fix asap. Thanks!
blocking-b2g: 2.0M? → 2.0M+
Flags: needinfo?(selee)
Priority: P2 → P1
Hi,

Changelist:
1. Remove Notifications from IDLE TEXT.

Please try it. Thank you.
Flags: needinfo?(selee)
Hi Sean Lee,
   The idle text still stays on notification bar after power off/on.please check the log.
Hi Pengfei,

The solution is tested on my Woodduck v2.0m (black) .
In this attachment, I add some logs for debugging.
Please help to test it again. Thank you.
Flags: needinfo?(pengfei.huang.hz)
Please use this one for test. (ignore the previous one - STK_PATCH_20141212_v2.tar.gz)
Hi Sean Lee,
   After merging patch STK_PATCH_20141212_v3.tar.gz ,I couldn't select STK menu item to do further testing, because the menu was stopping.And the same version code for bug1106454, I have to test them individually tomorrow. Thanks.
Flags: needinfo?(pengfei.huang.hz)
Hi Pengfei,

The crash is caused by that gsmLocationAreaCode can not be retrieved properly.
    DUMP('TESTCONN 4.1: ' + JSON.stringify(conn.voice.cell.gsmLocationAreaCode) );
    DUMP('TESTCONN 4.2: ' + JSON.stringify(conn.voice.cell.gsmCellId) );

Could you help to check you inserted the SIM card to Slot 1?
If not, please insert to slot 1 and test again.
IMHO, we could focus on the test case first, then multi-sim issue is the next item that we should resolve.

Thanks.
Flags: needinfo?(pengfei.huang.hz)
Fix the select item issue.
This can be for bug 1106450 and bug 1106454 as well.
The idle text was removed after power off/on.Check the log.
Flags: needinfo?(pengfei.huang.hz)
No longer blocks: Woodduck_P2
Blocks: Woodduck_P2
No longer blocks: Woodduck_P2
Hi Pengfei,

There are couple things that need your comments:
1. Could you help to provide the specification for this test case?
2. Per the test result in your comment 14, is this test case PASS?

Thank you.
Flags: needinfo?(pengfei.huang.hz)
Hi Sean Lee,
   Sorry reply in a hurry.The test result is expected and test pass.
   I need to ask VAL Project Manager for the permission of the specification of this test case.
   Many thanks your support.
Flags: needinfo?(pengfei.huang.hz)
Dear Sean,
Good job! Please process patch review. Thanks!
Flags: needinfo?(selee)
Attached file PR for master
Hello Fernando,

Here is my PR for this bug. Please help to review it. Thank you.
Flags: needinfo?(selee)
Attachment #8536407 - Flags: review?(frsela)
Comment on attachment 8536407 [details] [review]
PR for master

LGTM - f+
Cancelling review. I leave you a question in Github :)
Attachment #8536407 - Flags: review?(frsela) → feedback+
Flags: needinfo?(selee)
Hello Pengfei,

I need your help again for this bug. :P
I found a better way to wait for loading notifications.
Please help to test the trail patch and see whether there is any regression.

Thank you very much.
Flags: needinfo?(selee) → needinfo?(pengfei.huang.hz)
Ok,got it.
Flags: needinfo?(pengfei.huang.hz)
Hi Sean Lee, 
  I try your new patch and it works well. Test Pass.
How could I know what the event 'desktop-notification-resend' means? I can't find the event at developer.mozilla.org website.
Hi Pengfei,

Thanks a lot!

You can see the source code apps/system/js/notifications.js .
The event 'desktop-notification-resend' will be sent after mozResendAllNotifications .
Hello Fernando,

Thanks for your comments.
I've modified a better solution to wait for all notifications loaded.
Please help to review the PR again. Thank you.
Flags: needinfo?(frsela)
Comment on attachment 8536407 [details] [review]
PR for master

Much better :)
Thanks for taking care of it.
Flags: needinfo?(frsela)
Attachment #8536407 - Flags: review+
(In reply to Sean Lee [:seanlee] from comment #23)
> Hi Pengfei,
> 
> Thanks a lot!
> 
> You can see the source code apps/system/js/notifications.js .
> The event 'desktop-notification-resend' will be sent after
> mozResendAllNotifications .

And it's not meant for this kind of use. This is not the proper way to fix this on master: please use showOnlyOnce field of mozbehavior. This patch would do the trick on 2.0, because we don't have a better way.
Flags: needinfo?(selee)
Flags: needinfo?(mhenretty)
Flags: needinfo?(frsela)
(In reply to Alexandre LISSY :gerard-majax from comment #27)

> And it's not meant for this kind of use. This is not the proper way to fix
> this on master: please use showOnlyOnce field of mozbehavior. This patch
> would do the trick on 2.0, because we don't have a better way.

Sounds nice, but where is it documented? I didn't see it as a Notification option [1]

[1] https://developer.mozilla.org/en-US/docs/Web/API/notification
Flags: needinfo?(frsela) → needinfo?(lissyx+mozillians)
(In reply to Fernando R. Sela (no CC, needinfo please) [:frsela] from comment #28)
> (In reply to Alexandre LISSY :gerard-majax from comment #27)
> 
> > And it's not meant for this kind of use. This is not the proper way to fix
> > this on master: please use showOnlyOnce field of mozbehavior. This patch
> > would do the trick on 2.0, because we don't have a better way.
> 
> Sounds nice, but where is it documented? I didn't see it as a Notification
> option [1]
> 
> [1] https://developer.mozilla.org/en-US/docs/Web/API/notification

I'm not sure this should be exposed on MDN, but it's documented in bug 1100876.

Maybe Chris can help us here.
Flags: needinfo?(lissyx+mozillians) → needinfo?(cmills)
Hi Sean,
Can you raise PR for 2.0M since the schedule is tight for partner device launch? 
The discussion here might leads rework of master patch if necessary.
Thanks!
Agreed we should rework the master patch to use showOnlyOnce since scenarios like this are exactly what that was designed for. 

Also, I don't think we can document showOnlyOnce on the main web notification MDN page, since it's not an official part of the web notification spec (ie. desktop web doesn't have a need for reboot/resending notifications right now). Maybe we should document this moz only feature here: https://developer.mozilla.org/en-US/docs/Web/API/Notification/Using_Web_Notifications
Flags: needinfo?(mhenretty)
Hi Alexandre,

Thanks for your suggestions.
I will create a new bug for reworking the patch with showOnlyOnce for master as soon. ( I will take it. )
As Josh mentioned, this patch will apply to v2.0m because it needs for partner device .

Please ni me if you still have other concern.
Flags: needinfo?(selee)
Create a new bug 1112978 for reworking showOnlyOnce for IDLE MODE TEXT notifications.
(In reply to Alexandre LISSY :gerard-majax from comment #29)
> (In reply to Fernando R. Sela (no CC, needinfo please) [:frsela] from
> comment #28)
> > (In reply to Alexandre LISSY :gerard-majax from comment #27)
> > 
> > > And it's not meant for this kind of use. This is not the proper way to fix
> > > this on master: please use showOnlyOnce field of mozbehavior. This patch
> > > would do the trick on 2.0, because we don't have a better way.
> > 
> > Sounds nice, but where is it documented? I didn't see it as a Notification
> > option [1]
> > 
> > [1] https://developer.mozilla.org/en-US/docs/Web/API/notification
> 
> I'm not sure this should be exposed on MDN, but it's documented in bug
> 1100876.
> 
> Maybe Chris can help us here.

Can the NotificationBehaviour dictionary options be used as notification options when creating a new notification, as controllable by 3rd party app developers, or is it more of a system level Gaia thing? I don't really fully understand what they are, but once I understand better, I can make more of a decision.
Flags: needinfo?(cmills)
Dear DengWei,
   we can close this bug. see bug851802.
   Many thanks.
You need to log in before you can comment on or make changes to this bug.