832082 - Stk proactive command to display text does not function properly after receiving set idle mode text

Status: VERIFIED FIXED

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

Description

[Greg Grisco]

In GCF TC 27.22.4.22.1.4, the test is executed as follows:

- Start GCF test which prompts for device power up
- After power up and network registration is successful, GCF test prompts to select the idle screen if not already available
- The GCF test then asks if "Idle Mode Text" is displayed

Result:  Yes, we see the notification show up for idle mode text

- The GCF test sends an SMS and asks if the message is displayed

Result:  Yes, we see a notification for received SMS

- Then we are prompted to clear the message and select the idle screen if not already available

Result: we don't need to clear the message since it showed up as a notification and then went away.

- The GCF test asks if we can see the "Idle Mode Text".

Result: We can if we pull down the notification bar, so answer "yes".

- The GCF test sends a proactive command of Display Text and asks if we can see the message "Toolkit Test 1".

Result:  the message is not displayed.

The logs show that the message to display text was received:

02-02 18:36:04.989   123   123 I Gecko   : -*- RILContentHelper: Received message 'RIL:StkCommand': {"commandNumber":1,"typeOfCommand":33,"commandQualifier":128,"options":{"text":"Toolkit Test 1","userClear":true}}

Comment 1

[Greg Grisco]

We found that we could reproduce without sending the SMS.  Sending proactive command to display text followed by command to set idle mode text results in both being displayed properly.  But if you reverse the order then the display text is not shown.

The payloads we used for testing:

set idle mode text: {D01A8103012800820281828D0F0449646C65204D6F64652054657874}
display text: {D01A8103012180820281028D0F04546F6F6C6B697420546573742031}

Comment 2

[Andrew Overholt [:overholt]]

Yoshi, are you the best owner here?

Comment 3

[Fernando R. Sela (no CC, needinfo please) [:frsela]]

I just tested the {"commandNumber":1,"typeOfCommand":33,"commandQualifier":128,"options":{"text":"Toolkit Test 1","userClear":true}} command at UI level and it's working well.

Could you provide the other received STK commands (preferible in JSON format as this one ;)

Comment 4

[Yoshi Cheng-Hao Huang [:allstars.chh][:allstarschh][:yoshi]]

(In reply to Andrew Overholt [:overholt] from comment #2)
> Yoshi, are you the best owner here?

Seems it's a gaia bug.

Frsela,

I think you need to send the IDLE_MODE_TEXT command first,
then send DISPLAY_TEXT command.

Comment 5

[Fernando R. Sela (no CC, needinfo please) [:frsela]]

Theoretically, as soon as the UI receives the IDLE_MODE_TEXT, it's responded with STK_RESULT_OK after that, the message is displayed in the notification bar.

So the STK app is free to receive a second DISPLAY_TEXT command.

I tested to sent two commands and worked well.

Could you provide a logcat with all STK commands sent?

Comment 6

[Andrew Overholt [:overholt]]

Assigning to Fernando since it seems like he's investigating here.

Comment 7

[Greg Grisco]

Attachment: adb log with stk commands

Comment 8

[Anshul]

Fernando, do you have an update on this issue?

Comment 9

[Fernando R. Sela (no CC, needinfo please) [:frsela]]

(In reply to Anshul from comment #8)
> Fernando, do you have an update on this issue?

I've been away, now I get with it

Comment 10

[Fernando R. Sela (no CC, needinfo please) [:frsela]]

Detected the failure. Now the non-solicited STK messages are only received as System Message "icc-stkcommand" and not through "window.navigator.mozMobileConnection.icc.stkcommand" event handler.

Some time ago, both messages were sent so settings & system received the messages.

So it's needed that system notifies settings if this one is opened since settings didn't receive the message.

Working on it.

Comment 11

[Fernando R. Sela (no CC, needinfo please) [:frsela]]

Attachment: Manage Async STK commands also if settings is opened

Comment 12

[Fernando R. Sela (no CC, needinfo please) [:frsela]]

Comment on attachment 705837 [details]
Manage Async STK commands also if settings is opened

Vivien, Changes made.

Comment 13

[Vivien Nicolas (:vingtetun) (:21) - (NOT reading bugmails, needinfo? please)]

Comment on attachment 705837 [details]
Manage Async STK commands also if settings is opened

Don't forget to squash your commits and to add the bug number in the commit message.

Comment 14

[Fernando R. Sela (no CC, needinfo please) [:frsela]]

(In reply to Vivien Nicolas (:vingtetun) (:21) from comment #13)
> Comment on attachment 705837 [details]
> Manage Async STK commands also if settings is opened
> 
> Don't forget to squash your commits and to add the bug number in the commit
> message.

Thanks Vivien.
Squashed and landed in: https://github.com/mozilla-b2g/gaia/commit/cd217e574b202b2e8eb5e48498705e6cd750e457

Comment 15

[Greg Grisco]

I applied the patch and tested with IT3 machine but now I see the Settings application brought up instead of seeing notifcation of Setup Idle Mode Text being received.

Comment 16

[Fernando R. Sela (no CC, needinfo please) [:frsela]]

(In reply to ggrisco from comment #15)
> I applied the patch and tested with IT3 machine but now I see the Settings
> application brought up instead of seeing notifcation of Setup Idle Mode Text
> being received.

If I understood well, this is the WoW on FirefoxOS.

The message on the IDLE screen will be available until the handset is unlocked.

After that, the message will be show in the notification bar.

I'll provide some screenshots.

Comment 17

[Fernando R. Sela (no CC, needinfo please) [:frsela]]

Attachment: Screenshots showing the places where the message are showed

Comment 18

[Greg Grisco]

We retested today and the problem is a little bit different than what I reported in Comment 15 (sorry for the confusion).  Here is what we see:

1.  Notification of Setup Idle Mode Text is seen

The pulldown shows 1 notification

2.  Notification of incoming SMS is seen

The pulldown shows 2 notifications

3.  The Display Text popup is shown

The pulldown now only shows 1 notification.  The Setup Idle Mode Text notification has been dropped from the list.

Continuing on, the test attempts to play dial tone which also isn't being heard.  The command is 

{D01B81030120008202810385094469616C20546F6E658E010184020105}

Not sure if it is related at all to this bug or whether it should be handled in a separate bugzilla.

Comment 19

[Fernando R. Sela (no CC, needinfo please) [:frsela]]

(In reply to ggrisco from comment #18)
> We retested today and the problem is a little bit different than what I
> reported in Comment 15 (sorry for the confusion).  Here is what we see:
> 
> 1.  Notification of Setup Idle Mode Text is seen
> 
> The pulldown shows 1 notification
> 
> 2.  Notification of incoming SMS is seen
> 
> The pulldown shows 2 notifications
> 
> 3.  The Display Text popup is shown
> 
> The pulldown now only shows 1 notification.  The Setup Idle Mode Text
> notification has been dropped from the list.
> 

The notifications showed on the notif. bar will be removed when the target app is opened. For example, if you receive an SMS, this will be showed in the notif. bar and you've two options:

 1.- Open the notif. bar and touch on the notification which opens SMS app & remove notification

 2.- Open SMS app directly which also removes notification

I think in your case, the notification is removed cause the settings app is opened and the IDLE MODE TEXT notification is targeted to settings app.

> Continuing on, the test attempts to play dial tone which also isn't being
> heard.  The command is 
> 
> {D01B81030120008202810385094469616C20546F6E658E010184020105}
> 
> Not sure if it is related at all to this bug or whether it should be handled
> in a separate bugzilla.

Ummm, some logcat with settings and system apps debug enabled will be great to follow this other issue.

Comment 20

[Fernando R. Sela (no CC, needinfo please) [:frsela]]

(In reply to ggrisco from comment #18)
> Continuing on, the test attempts to play dial tone which also isn't being
> heard.  The command is 
> 
> {D01B81030120008202810385094469616C20546F6E658E010184020105}
> 
> Not sure if it is related at all to this bug or whether it should be handled
> in a separate bugzilla.

One more question, this PLAY TONE bug is related with bug #836135?

Comment 21

[Lukas Blakk [:lsblakk] use ?needinfo]

(In reply to Fernando R. Sela [:frsela] from comment #14)

> Squashed and landed in:
> https://github.com/mozilla-b2g/gaia/commit/
> cd217e574b202b2e8eb5e48498705e6cd750e457

Can you confirm that this landed on v1-train and v1.0.0 then mark the status-b2g18 & status-b2g18-v1.0.0 flags as 'fixed' if/when it is landed on those branches?

Comment 22

[Greg Grisco]

(In reply to Fernando R. Sela [:frsela] from comment #19)

The GCF test will fail since its purpose is to test competing info. Even though IDLE_MODE_TEXT is targeted to settings app, opening settings app does not allow the user to view the actual text (only viewable from notification bar or selecting it from notification bar). It would seem that the user may never get a chance to view the IDLE_MODE_TEXT if any other STK commands come after it.  I think it's still important that we find a solution for this.

Comment 23

[Fernando R. Sela (no CC, needinfo please) [:frsela]]

(In reply to Lukas Blakk [:lsblakk] from comment #21)
> (In reply to Fernando R. Sela [:frsela] from comment #14)
> 
> > Squashed and landed in:
> > https://github.com/mozilla-b2g/gaia/commit/
> > cd217e574b202b2e8eb5e48498705e6cd750e457
> 
> Can you confirm that this landed on v1-train and v1.0.0 then mark the
> status-b2g18 & status-b2g18-v1.0.0 flags as 'fixed' if/when it is landed on
> those branches?

In v.1.0.0 is not landed
In v1-train is not landed too

Comment 24

[Fernando R. Sela (no CC, needinfo please) [:frsela]]

(In reply to ggrisco from comment #22)
> (In reply to Fernando R. Sela [:frsela] from comment #19)
> 
> The GCF test will fail since its purpose is to test competing info. Even
> though IDLE_MODE_TEXT is targeted to settings app, opening settings app does
> not allow the user to view the actual text (only viewable from notification
> bar or selecting it from notification bar). It would seem that the user may
> never get a chance to view the IDLE_MODE_TEXT if any other STK commands come
> after it.  I think it's still important that we find a solution for this.

Show a popup as soon as settings is opened with the pending message?

Comment 25

[Fernando R. Sela (no CC, needinfo please) [:frsela]]

Adding more information about this new issue.
The notification helper changed to work this way:

  https://bugzilla.mozilla.org/show_bug.cgi?id=824549#c13

So we've little options:

1.- Open a dialog when settings is opened if pending notificatons are not attended?

2.- Add additional hack to notifications to avoid this WoW with settings app?

  -> Checking the manifest in this part: https://bugzilla.mozilla.org/attachment.cgi?id=702913&action=diff#a/apps/system/js/notifications.js_sec3

3.- Add additional parameter to notifications to avoid this WoW with them.

Vivien, WDYT is the best approach? Any other cool idea? ;)

Comment 26

[Vivien Nicolas (:vingtetun) (:21) - (NOT reading bugmails, needinfo? please)]

Look at the blocking bug for this one. 

If you add a system message for 'notification' you will be able to receive a message with navigator.setMessageHandler('notification', foo()) and check if the user has seen the notification or not. You will then be able to show the user a dialog or whatever containing the text if needed.

Does it works for you?

Comment 27

[Fernando R. Sela (no CC, needinfo please) [:frsela]]

(In reply to Vivien Nicolas (:vingtetun) (:21) from comment #26)
> Look at the blocking bug for this one. 
> 
> If you add a system message for 'notification' you will be able to receive a
> message with navigator.setMessageHandler('notification', foo()) and check if
> the user has seen the notification or not. You will then be able to show the
> user a dialog or whatever containing the text if needed.
> 
> Does it works for you?

yes, the callback is defined. but, is this callback called when the settings app is opened but is not opened through the notification?

I mean, if I press the notification, the callback is called but if I use the desktop icon I think it's not called and the notif. is removed

Comment 28

[Vivien Nicolas (:vingtetun) (:21) - (NOT reading bugmails, needinfo? please)]

(In reply to Fernando R. Sela [:frsela] from comment #27)
> (In reply to Vivien Nicolas (:vingtetun) (:21) from comment #26)
> > Look at the blocking bug for this one. 
> > 
> > If you add a system message for 'notification' you will be able to receive a
> > message with navigator.setMessageHandler('notification', foo()) and check if
> > the user has seen the notification or not. You will then be able to show the
> > user a dialog or whatever containing the text if needed.
> > 
> > Does it works for you?
> 
> yes, the callback is defined. but, is this callback called when the settings
> app is opened but is not opened through the notification?
> 
> I mean, if I press the notification, the callback is called but if I use the
> desktop icon I think it's not called and the notif. is removed

Does the onclose method of the desktop notification not called?  (The second callback of the NotificationHelper.send method - which you don't use actually)

Comment 29

[Fernando R. Sela (no CC, needinfo please) [:frsela]]

(In reply to Vivien Nicolas (:vingtetun) (:21) from comment #28)
> (In reply to Fernando R. Sela [:frsela] from comment #27)
> > (In reply to Vivien Nicolas (:vingtetun) (:21) from comment #26)
> > > Look at the blocking bug for this one. 
> > > 
> > > If you add a system message for 'notification' you will be able to receive a
> > > message with navigator.setMessageHandler('notification', foo()) and check if
> > > the user has seen the notification or not. You will then be able to show the
> > > user a dialog or whatever containing the text if needed.
> > > 
> > > Does it works for you?
> > 
> > yes, the callback is defined. but, is this callback called when the settings
> > app is opened but is not opened through the notification?
> > 
> > I mean, if I press the notification, the callback is called but if I use the
> > desktop icon I think it's not called and the notif. is removed
> 
> Does the onclose method of the desktop notification not called?  (The second
> callback of the NotificationHelper.send method - which you don't use
> actually)

Oh, nice. I'll add it. Thanks

Comment 30

[Fernando R. Sela (no CC, needinfo please) [:frsela]]

Attachment: [WIP] STK Notifications with close callback too

Vivien, You mean this?

@ggrisco: This solves the issue?

Comment 31

[Vivien Nicolas (:vingtetun) (:21) - (NOT reading bugmails, needinfo? please)]

(In reply to Fernando R. Sela [:frsela] from comment #30)
> Created attachment 708689 [details] [diff] [review]
> [WIP] STK Notifications with close callback too
> 
> Vivien, You mean this?

Something similar.

I think the issue with this right now is the fact that the application will not be move in foreground when the user click on the notification. (You also want to listen see how it is done in apps/sms/js/sms.js with app.launch().)

You probably also does not want to put the application in foreground if you enter the second callback.

Comment 32

[Fernando R. Sela (no CC, needinfo please) [:frsela]]

Attachment: STK Notifications with close callback too

Comment 33

[Vivien Nicolas (:vingtetun) (:21) - (NOT reading bugmails, needinfo? please)]

Comment on attachment 708966 [details]
STK Notifications with close callback too

This code will always put the Settings Application in foreground when you display a notification, even if the user dismiss it manually. I believe this is not what you want.

What about:

// The user has clicked the notification, let's focus the application and show the content
// of the notification.
function onClick() {
  // If the document is already visible, just display the message.
  if (document.mozHidden == false) {
    alert(options.text); 
    return;
  }

  // The application is not currently focused, let's move it on the foreground
  navigator.mozApps.getSelf().onsuccess = function getSelfCB(evt) {
    var app =  evt.target.result;
    app.launch();
    alert(options.text);
  }
}

// The user has cancelled the notification or the notification has been closed when
// the application has been opened. In any case, this is an important message so let's
// show the user the message when it comes back to the application or show it
// instantly if the application is already focused.
function onCancel() {
  if (document.mozHidden == false) {
    alert(options.text);
    return;
  }

  // The notification has been closed and the message could not have been seen.
  // This is an important message so let's show it once the application goes visible again.
  window.addEventListener('mozvisibilitychange', function showClosedNotification(e) {
    window.removeEventListener(e.type, showClosedNotification);
    alert(options.text);
  }
}


This offers more granularity and less annoyance to the user but I don't know if that's will be enough for passing the test?

Comment 34

[Fernando R. Sela (no CC, needinfo please) [:frsela]]

(In reply to Vivien Nicolas (:vingtetun) (:21) from comment #33)

> This offers more granularity and less annoyance to the user but I don't know
> if that's will be enough for passing the test?

I'm not really sure what's needed for passing the GCF test. Anyway I'll upload another patch with your suggestion.

Comment 35

[Fernando R. Sela (no CC, needinfo please) [:frsela]]

Comment on attachment 708966 [details]
STK Notifications with close callback too

Vivien, I changed the CB with your code. Thanks.

Comment 36

[Greg Grisco]

So, we tested again this morning with both patches and yes now when the display text comes, the Set Idle Mode text is shown in a dialog above the display text.  This feels a little strange because it's blocking the view of the display text.

A potentially bigger problem is that later on in the test a dial tone command is sent, after which the test asks to verify that set idle mode text can still be seen.  Of course, the set idle mode text has already been removed from the notifcation list and the popup has already been dismissed so there is no way to retrieve this information.  I'm not sure yet whether the test team will view this as pass or not, but I'm suspecting that they will fail the test case still.

Comment 37

[Fernando R. Sela (no CC, needinfo please) [:frsela]]

(In reply to ggrisco from comment #36)
> So, we tested again this morning with both patches and yes now when the
> display text comes, the Set Idle Mode text is shown in a dialog above the
> display text.  This feels a little strange because it's blocking the view of
> the display text.
> 
> A potentially bigger problem is that later on in the test a dial tone
> command is sent, after which the test asks to verify that set idle mode text
> can still be seen.  Of course, the set idle mode text has already been
> removed from the notifcation list and the popup has already been dismissed
> so there is no way to retrieve this information.  I'm not sure yet whether
> the test team will view this as pass or not, but I'm suspecting that they
> will fail the test case still.

Thank you for your feedback.

With your explanation I understand that the IDLE text never should be removed automatically.

AFAIK the real WoW of this use case is: When STK_CMD_SET_UP_IDLE_MODE_TEXT is received an IDLE text is showed until STK_CMD_REFRESH (https://github.com/frsela/gaia/blob/master/apps/settings/js/icc.js#L266) is called.

Anyway, in FirefoxOS we only can show IDLE messages with the notificationhelper which are removed when the attendant app is opened.

NotificationHelper doesn't have a method to remove messages, that's the reason clearNotification (https://github.com/frsela/gaia/blob/master/apps/settings/js/icc.js#L837) isn't yet implemented.

I think the only way to solve this is to add a new helper to maintain notifications more time, anyway this is another bug (since this is out of the STK scope) and I'm not sure if we should afford this for the current release.

@dcoloma: WDYT?

Comment 38

[Vivien Nicolas (:vingtetun) (:21) - (NOT reading bugmails, needinfo? please)]

(In reply to Fernando R. Sela [:frsela] from comment #37)
> (In reply to ggrisco from comment #36)
> > So, we tested again this morning with both patches and yes now when the
> > display text comes, the Set Idle Mode text is shown in a dialog above the
> > display text.  This feels a little strange because it's blocking the view of
> > the display text.
> > 
> > A potentially bigger problem is that later on in the test a dial tone
> > command is sent, after which the test asks to verify that set idle mode text
> > can still be seen.  Of course, the set idle mode text has already been
> > removed from the notifcation list and the popup has already been dismissed
> > so there is no way to retrieve this information.  I'm not sure yet whether
> > the test team will view this as pass or not, but I'm suspecting that they
> > will fail the test case still.
> 
> Thank you for your feedback.
> 
> With your explanation I understand that the IDLE text never should be
> removed automatically.
> 
> AFAIK the real WoW of this use case is: When STK_CMD_SET_UP_IDLE_MODE_TEXT
> is received an IDLE text is showed until STK_CMD_REFRESH
> (https://github.com/frsela/gaia/blob/master/apps/settings/js/icc.js#L266) is
> called.
> 
> Anyway, in FirefoxOS we only can show IDLE messages with the
> notificationhelper which are removed when the attendant app is opened.
> 
> NotificationHelper doesn't have a method to remove messages, that's the
> reason clearNotification
> (https://github.com/frsela/gaia/blob/master/apps/settings/js/icc.js#L837)
> isn't yet implemented.
> 
> I think the only way to solve this is to add a new helper to maintain
> notifications more time, anyway this is another bug (since this is out of
> the STK scope) and I'm not sure if we should afford this for the current
> release.
> 
> @dcoloma: WDYT?

Maybe a dirty solution could be:
 - instead of opening an alert that shown the STK_DISPLAY_IDLE_MODE_TEXT when the user enters the settings app we can call NotificationHelper.send(the_old_notification_content) ?

This will add back the notification in the notification center. The trick here is to do that until the user click it volontarily or until a STK_COMMAND_REFRESH is received.

Then when you receive a STK_COMMAND_REFRESH does the settings app needs to be put in the foreground? If yes that means the notification will be cleared because of the app opening and then you will be able to not call NotificationHelper.send this time.

wdyt?

Comment 39

[Fernando R. Sela (no CC, needinfo please) [:frsela]]

(In reply to Vivien Nicolas (:vingtetun) (:21) from comment #38)
> Maybe a dirty solution could be:
>  - instead of opening an alert that shown the STK_DISPLAY_IDLE_MODE_TEXT
> when the user enters the settings app we can call
> NotificationHelper.send(the_old_notification_content) ?
> 
> This will add back the notification in the notification center. The trick
> here is to do that until the user click it volontarily or until a
> STK_COMMAND_REFRESH is received.
> 
> Then when you receive a STK_COMMAND_REFRESH does the settings app needs to
> be put in the foreground? If yes that means the notification will be cleared
> because of the app opening and then you will be able to not call
> NotificationHelper.send this time.
> 
> wdyt?

I thought that but as you told I think this is a very dirty solution but can work.

I'm not sure the user feedback seeing notifications appearing again and again ... In android phones this kind of notifications are showed in a different area to differenciate them but we'll show on the same place.

As told in the first paragraph, this can work but is a dirty solution. If all of you want this WoW, I'll drive these changes.

Comment 40

[Vivien Nicolas (:vingtetun) (:21) - (NOT reading bugmails, needinfo? please)]

(In reply to Fernando R. Sela [:frsela] from comment #39)
> (In reply to Vivien Nicolas (:vingtetun) (:21) from comment #38)
> > Maybe a dirty solution could be:
> >  - instead of opening an alert that shown the STK_DISPLAY_IDLE_MODE_TEXT
> > when the user enters the settings app we can call
> > NotificationHelper.send(the_old_notification_content) ?
> > 
> > This will add back the notification in the notification center. The trick
> > here is to do that until the user click it volontarily or until a
> > STK_COMMAND_REFRESH is received.
> > 
> > Then when you receive a STK_COMMAND_REFRESH does the settings app needs to
> > be put in the foreground? If yes that means the notification will be cleared
> > because of the app opening and then you will be able to not call
> > NotificationHelper.send this time.
> > 
> > wdyt?
> 
> I thought that but as you told I think this is a very dirty solution but can
> work.
> 
> I'm not sure the user feedback seeing notifications appearing again and
> again ... In android phones this kind of notifications are showed in a
> different area to differenciate them but we'll show on the same place.
> 
> As told in the first paragraph, this can work but is a dirty solution. If
> all of you want this WoW, I'll drive these changes.

I don't want anything particularly :) I know that the Web Notifications API is not ready yet and so there is no method for an application to remove notifications from the notifications center. As a workaround those notifications are removed when the application is opened. 

About the user experience what I wonder is: how often this stuff happens?

Comment 41

[Daniel Coloma:dcoloma]

We have tested this command in an Android device and the behaviour does not comply with GCF tests either. Based on the comments above I suggest we don't fix this one, keeps the current solution that is good enough imho and ask for GCF leniency in this particular bug. Is that OK with you George?

Comment 42

[Vivien Nicolas (:vingtetun) (:21) - (NOT reading bugmails, needinfo? please)]

(In reply to Daniel Coloma:dcoloma from comment #41)
> We have tested this command in an Android device and the behaviour does not
> comply with GCF tests either. Based on the comments above I suggest we don't
> fix this one, keeps the current solution that is good enough imho and ask
> for GCF leniency in this particular bug. Is that OK with you George?

I have been told that Android has a special mode to pass CGF test? Have you heard about it?

Comment 43

[Greg Grisco]

(In reply to Daniel Coloma:dcoloma from comment #41)

If you want to add this to the list of TC's that you plan have waived, then I'm ok with closing this bug out.

Comment 44

[Vivien Nicolas (:vingtetun) (:21) - (NOT reading bugmails, needinfo? please)]

Comment on attachment 708966 [details]
STK Notifications with close callback too

Removing the review - ask me again if needed.

Comment 45

[David Palomino [:dpalomino]]

> 
> I have been told that Android has a special mode to pass CGF test? Have you
> heard about it?

Hi Vivien, 

I haven't heard about this, maybe Michael could provide more info on this. 

@mvines: do you know if this "special mode" for Android exists?

Thanks!
David

Comment 46

[Michael Vines [:m1] [:evilmachines]]

I haven't heard of this.

Comment 47

[Fernando R. Sela (no CC, needinfo please) [:frsela]]

As discussed in the last comments, I close this bug as WONTFIX.

We'll return to it in version 2.

Comment 48

[John Ford [:jhford] CET/CEST Berlin Time]

(In reply to Fernando R. Sela [:frsela] from comment #47)
> As discussed in the last comments, I close this bug as WONTFIX.
> 
> We'll return to it in version 2.

should we clear tef+ and the status-b2g18* flags?

Comment 49

[Fernando R. Sela (no CC, needinfo please) [:frsela]]

(In reply to John Ford [:jhford] from comment #48)
> (In reply to Fernando R. Sela [:frsela] from comment #47)
> > As discussed in the last comments, I close this bug as WONTFIX.
> > 
> > We'll return to it in version 2.
> 
> should we clear tef+ and the status-b2g18* flags?

I suppose that, but asking Daniel . . .

Comment 50

[Daniel Coloma:dcoloma]

(In reply to John Ford [:jhford] from comment #48)
> (In reply to Fernando R. Sela [:frsela] from comment #47)
> > As discussed in the last comments, I close this bug as WONTFIX.
> > 
> > We'll return to it in version 2.
> 
> should we clear tef+ and the status-b2g18* flags?

Yes (I suppose), and also the dependency on the Commercial Software flag?

Comment 51

[Lukas Blakk [:lsblakk] use ?needinfo]

Batch edit: Bugs still affected on b2g18 after 2/13 merge to v1.0.1 branch are affected on v1.0.1 branch.

Comment 52

[Julien Wajsberg [:julienw]]

Hey, I don't exactly get this bug.

I think part of it landed on master:
https://github.com/mozilla-b2g/gaia/commit/cd217e574b202b2e8eb5e48498705e6cd750e457

was this the first patch ? And the WONTFIX resolution concerns the second patch ?

Then, if this was tef+ or tracking+, this will need to go to v1.0.1 and v1-train. Is this correct ? Or do we have to backout this patch from master too ?

Comment 53

[Fernando R. Sela (no CC, needinfo please) [:frsela]]

(In reply to Julien Wajsberg [:julienw] from comment #52)
> Hey, I don't exactly get this bug.
> 
> I think part of it landed on master:
> https://github.com/mozilla-b2g/gaia/commit/
> cd217e574b202b2e8eb5e48498705e6cd750e457
> 
> was this the first patch ? And the WONTFIX resolution concerns the second
> patch ?
> 
> Then, if this was tef+ or tracking+, this will need to go to v1.0.1 and
> v1-train. Is this correct ? Or do we have to backout this patch from master
> too ?

Yes, on comment 15 the bug has been reopened but after some tricky (and dirty) hacks we decided to WONTFIX the second "issue" commented in #15 since it's a dirty hack and other platforms (like Android) didn't care about this too.

We suggested to move it to V2 when the NotificiationHelper implementes more features like remove messages, group notifications and set non-deletable notifications (needed here ;)

Comment 54

[Julien Wajsberg [:julienw]]

Thanks Fernando, then I set it to FIXED instead of WONTFIX. (not sure which one is the good one, but FIXED feels better to me)

John, could you proceed with the uplift of cd217e574b202b2e8eb5e48498705e6cd750e457 to v1-train and v1.0.1 then ? Thanks !

Comment 55

[John Ford [:jhford] CET/CEST Berlin Time]

v1-train: fb6282e6e9bb6e2c851a8d9408526bf11a31be90
v1.0.1: cf02734260d5775843a91f72f74685becde72cbb

Comment 56

[amiller]

Build ID: 20130329070203 
Kernel Date: Dec 5
Gecko: http://hg.mozilla.org/releases/mozilla-b2g18/rev/5cc5df16447a
Gaia: 26b463f14caa11e0fc64fda09a17054da4bea68b

Verified as fixed in V1 train. I see the Settings application brought up instead of seeing notifcation of Setup Idle Mode Text being received.