Closed Bug 846966 Opened 8 years ago Closed 7 years ago
STK: Subsequent SET
_UP _IDLE _MODE _TEXT does not replace the current idle mode text
According to ETSI TS 102 223, section 6.4.22: "Any subsequent SET UP IDLE MODE TEXT command replaces the current idle mode text of the previous SET UP IDLE MODE TEXT." Currently, any subsequent SET_UP_IDLE_MODE_TEXT is added on top of the previous idle mode texts. Please see screenshots attached. On Android, once the subsequent SET_UP_IDLE_MODE_TEXT came, the previous one was removed from the notification area, replaced with the new text.
As commented in bug 846968, in the current Notification Bar API we cann't remove previous notifications nor create group of notifications.
8 years ago
Depends on: 782211
I don't think this should be blocking. The notification API does not allow for replacement of notifications. This is an enhancement request for the notification API that we don't have time to implement for 1.0.1.
Lucas, is it doable in the Leo time frame? We will mark this GCF TC as NA.
blocking-b2g: tef+ → leo?
Looks like we are depending on the right bug 782211 here, so we'll track progress there. That bug is not a user story for Leo so it won't block, but we'd take the fix if it lands soon.
I nominated this bug only because bug 873910 was nominated, but this is under discussion for waiver in 1.0.1. Please do not tef+/- unless you are on that email thread.
triage with partner: going for waiver on this for v1.0.1, leo? for next release consideration
blocking-b2g: tef? → leo?
Triage - partner would like to have this fixed for 1.1 if low complexity, but not blocking release. Hi Etienne, per comment 1, do we have a plan for notification bar api to support this?
blocking-b2g: leo? → ---
After reviewing STK bugs related to notification helper, I've noticed that Bug 873397 is marked as leo+, in order to have the expected behavior, both of them should be fixed at the same time so nominating this for leo? again.
blocking-b2g: --- → leo?
Depends on: 873397
(In reply to Wayne Chang [:wchang] from comment #8) > Triage - partner would like to have this fixed for 1.1 if low complexity, > but not blocking release. > > Hi Etienne, per comment 1, do we have a plan for notification bar api to > support this? Yes! Being able to update a notification is part of the spec. (Don't have any idea when we plan to adopt the new notification API though.)
(In reply to Etienne Segonzac (:etienne) from comment #10) > > Yes! Being able to update a notification is part of the spec. > (Don't have any idea when we plan to adopt the new notification API though.) We should do that for 1.2
triage - By comment 10 and comment 11, this would not be in time for leo and also not part of the original scope.
blocking-b2g: leo? → ---
8 years ago
Duplicate of this bug: 846968
Hi Carol, 6 days ago I worked in a new patch for 873397 which implements this STK method with the new notification API. In this new patch (https://github.com/mozilla-b2g/gaia/pull/16984) I consider that subsequent messages will replace the previous one. (https://github.com/mozilla-b2g/gaia/pull/16984/files#diff-5a6489711b0f6e366fbefde28f3ce078R492 - same tag attribute per SIM) Can we close this bug as soon as this patch is landed?
Hi Fernando, Thanks so much for the update! I'm going to have Nivi test your patch and comment if anything doesn't look right. Otherwise, yes, sounds good to close this bug if it's fixed.
Flags: needinfo?(cyang) → needinfo?(nsarkar)
Thanks Fernando. The change works great. Nivi.
(In reply to Nivi from comment #16) > Thanks Fernando. The change works great. > > Nivi. \o/ Thank you Carol & Nivi Closing as duplicate since the new patch is valid to solve also this one.
Status: NEW → RESOLVED
Closed: 7 years ago
Resolution: --- → DUPLICATE
Duplicate of bug: 873397
You need to log in before you can comment on or make changes to this bug.