Closed Bug 1026685 (cmas-application) Opened 6 years ago Closed 6 years ago

CMAS Alert channel support

Categories

(Firefox OS Graveyard :: Gaia::Network Alerts, defect)

x86
macOS
defect
Not set

Tracking

(feature-b2g:2.1, tracking-b2g:backlog)

VERIFIED FIXED
2.1 S3 (29aug)
feature-b2g 2.1
tracking-b2g backlog

People

(Reporter: wmathanaraj, Assigned: steveck)

References

Details

(Keywords: feature, meta, Whiteboard: [tako][2.1-feature-qa+])

User Story

As a user I expect all alert channels to be supported for NL, LT and Chile. (specs attached)

AC1: i want to play an audible sound
AC2: I want to be able to dismiss a message
AC3: I want to see the last message sent on each channel

Attachments

(7 files, 1 obsolete file)

No description provided.
blocking-b2g: --- → backlog
feature-b2g: --- → 2.1
User Story: (updated)
Keywords: feature
Whiteboard: [tako]
We'll need UX on this.
Flags: needinfo?(jelee)
Hi UX, we also need an on/off toggle in Settings, see bug 1032651 , thank you.
Hello Wilfred, can you be more specific on "AC3 : I want to see the last message sent on each channel" ? Thank you ;)
Flags: needinfo?(wmathanaraj)
Hello Wilfred, another question for you. I'm planning to add a toggle for user to turn on/off CMAS, the toggle will be in messaging setting, under cell broadcast toggle. Will toggle cell broadcast on/off affect CMAS? ex. turning off cell broadcast will also turn off CMAS or should they function independently? Let me know, tks!!
Flags: needinfo?(jelee)
Attached file [2.1 Message] CMAS v1.0.pdf (obsolete) —
Hi all, please see attached for CMAS support spec. Thank you!
yes they should be linked.
Flags: needinfo?(wmathanaraj)
QA Whiteboard: [COM=Gaia::SMS]
See Also: → 1032651
(In reply to Jenny Lee from comment #8)
> Created attachment 8452848 [details]
> [2.1 Message] CMAS v1.0.pdf
> 
> Hi all, please see attached for CMAS support spec. Thank you!

As Wilfred mentioned, CB and CMAS toggling should be linked. It's not going to work to have separate toggle panels.
(In reply to Hsin-Yi Tsai [:hsinyi] from comment #10)
> (In reply to Jenny Lee from comment #8)
> > Created attachment 8452848 [details]
> > [2.1 Message] CMAS v1.0.pdf
> > 
> > Hi all, please see attached for CMAS support spec. Thank you!
> 
> As Wilfred mentioned, CB and CMAS toggling should be linked. It's not going
> to work to have separate toggle panels.
After offline discussion, if CB on, CMAS message could be filtered at Gaia side.

So Wilfred, I'd like to confirm with you if this is the final requirement:
1. Two toggles, CB and CMAS
2. When CB on, user can turn on/off the CMAS
3. When CB off, CMAS is also off for sure.
Flags: needinfo?(wmathanaraj)
correct. this is the final requirement
Flags: needinfo?(wmathanaraj)
Hi all, please take a look at the latest CMAS spec. For setting related, see Message setting meta bug Bug 1001285 attachment 8462381 [details], thank you.
Attachment #8452848 - Attachment is obsolete: true
Hi Jenny,

The spec appear to describe the behaviour for multiple requests pending user acknowledgement.  Newest should be displayed first.  https://bugzilla.mozilla.org/show_bug.cgi?id=1039617

M
(In reply to Michael Schwartz [:m4] from comment #14)
Hi Michael, yes newest should be displayed first. Thanks for pointing that out!
See Also: 1032651
Start Settings UI implementation in bug 1032651 based on comment 11

I'd use 'ril.cellbroadcast.cmas.disabled' as mozSettings key for CMAS if no objection.
(In reply to Fred Lin [:gasolin] from comment #16)
> Start Settings UI implementation in bug 1032651 based on comment 11
> 
> I'd use 'ril.cellbroadcast.cmas.disabled' as mozSettings key for CMAS if no
> objection.

If it's possible, I'd prefer "ril.cellbroadcast.cmas.enabled" or even just "ril.cellbroadcast.cmas" to avoid double negations (ril.cellbroadcast.cmas.disabled === false).
`ril.cellbroadcast.cmas.enabled` make sense.

I try to choose this param by follow the existing naming 'ril.cellbroadcast.disabled'
http://dxr.mozilla.org/mozilla-central/source/dom/system/gonk/RadioInterfaceLayer.js#87

Seems these two keys usually sit together, maybe `ril.cellbroadcast.cmas.disabled` is better for naming consistency?
How about simply 'cmas.enabled'?
@Vicamo is there any concern for the CMAS property naming?
Flags: needinfo?(vyang)
(In reply to Fred Lin [:gasolin] from comment #20)
> @Vicamo is there any concern for the CMAS property naming?

No, that has nothing to do with Gecko. CMAS enable/disable is merely insertion/removal of CMAS channels to existing CB search list as HsinYi had pointed out in comment 10. No additional tricks added to Gecko, neither new mozSettings keys in concerned. That's a Gaia-only setting. You may choose anything you like except that "ril" prefix. Arthur's suggestion in comment 19 is good enough.
Flags: needinfo?(vyang)
ok, thanks for clarification :)

Since it's not related to gecko, I'd like to take 'cmas.enabled' as settings key.
Good for me :)
Jenny, I have some questions for you.

1. display the notifications
* I'd like to use the standard Notification API for this. But this has these implications:
  - We'll have the vibrate + sound of the notification. It will happen after the user taps 
    the "OK" of the message, when we'll send the notification
  - it won't stay at the top of the notification screen. Maybe we can work with the 
    notification guys to have a "important" status, but nothing is sure here.
  - the notification will be displayed in the lockscreen too

2. display the dialog box
* I'd like to use the attention screen feature. I still need to do some test, but I think it 
  takes the whole screen. So we can probably do something like the Dialer does to simulate that
  the lockscreen stays behind, but if you want, we can also show something different on the
  whole screen.

Please tell me your thoughts on this!
Flags: needinfo?(jelee)
(In reply to Julien Wajsberg [:julienw] from comment #24)
> Jenny, I have some questions for you.
> 
> 1. display the notifications
> * I'd like to use the standard Notification API for this. But this has these
> implications:
>   - We'll have the vibrate + sound of the notification. It will happen after
> the user taps 
>     the "OK" of the message, when we'll send the notification
>   - it won't stay at the top of the notification screen. Maybe we can work
> with the 
>     notification guys to have a "important" status, but nothing is sure here.
>   - the notification will be displayed in the lockscreen too
> 
I realize what I have in mind is not how standard notification works. When user tap on the ok button, we don't actually send a notification, we simply add a notification in the tray (no sound+vibrate or on screen display). Is that doable?
As for the the order of CMAS notifications, I've discussed this with several UX designers and we all think it makes sense to keep them all on top. Again, is that doable?  

> 2. display the dialog box
> * I'd like to use the attention screen feature. I still need to do some
> test, but I think it 
>   takes the whole screen. So we can probably do something like the Dialer
> does to simulate that
>   the lockscreen stays behind, but if you want, we can also show something
> different on the
>   whole screen.
> 
I'm ok with using attention screen (I just found out that dialog can't wake the screen). Maybe we can apply dialog style and use attention screen? Thanks!
Flags: needinfo?(jelee)
(In reply to Jenny Lee from comment #25)
> (In reply to Julien Wajsberg [:julienw] from comment #24)
> > Jenny, I have some questions for you.
> > 
> > 1. display the notifications
> > * I'd like to use the standard Notification API for this. But this has these
> > implications:
> >   - We'll have the vibrate + sound of the notification. It will happen after
> > the user taps 
> >     the "OK" of the message, when we'll send the notification
> >   - it won't stay at the top of the notification screen. Maybe we can work
> > with the 
> >     notification guys to have a "important" status, but nothing is sure here.
> >   - the notification will be displayed in the lockscreen too
> > 
> I realize what I have in mind is not how standard notification works. When
> user tap on the ok button, we don't actually send a notification, we simply
> add a notification in the tray (no sound+vibrate or on screen display). Is
> that doable?

If we take the "external application" approach, I think it's not, and I'd be very sad if this is the only thing that prevents it :(

> As for the the order of CMAS notifications, I've discussed this with several
> UX designers and we all think it makes sense to keep them all on top. Again,
> is that doable?  

I'll ask the Notification peers, I think we can find a solution about this.

> 
> > 2. display the dialog box
> > * I'd like to use the attention screen feature. I still need to do some
> > test, but I think it 
> >   takes the whole screen. So we can probably do something like the Dialer
> > does to simulate that
> >   the lockscreen stays behind, but if you want, we can also show something
> > different on the
> >   whole screen.
> > 
> I'm ok with using attention screen (I just found out that dialog can't wake
> the screen). Maybe we can apply dialog style and use attention screen?
> Thanks!

I'm doing a POC using the attention screen right now, I'll be able to share today so that we can see what is acceptable and what is not :)
Here is a POC using an external application:
https://github.com/julienw/gaia/compare/cmas-poc?expand=1

From my point of view it works really well. I did 2 different styles:
* one style displays the alert message in the full window
* another style uses a dialog-like style

You can simple try it by tapping the right button in the fake app.

To install it, you need to a reset-gaia (because it's a new app and it has permissions). It has no icon (so the default icon is used) and the name is CMAS. In the final application, it would have a role "system" so that it does not display in the homescreen and is triggered by a system message instead.
Attached video CMAS POC
Hey Jenny,

in this video, you can see the POC I made for CMAS. The video dropped some frames sometimes so you'll see that it "jumps" sometimes.

Especially, the first time we have the grey banner at the top, it's really the attention screen that is reduced by rpessing the "home" button (like when we're in a call). We can see the same thing at the end of the video.

I also made 2 different styles: one style is more "dialog", where we see the background, while another style is "fullscreen".

Seeing this, I wonder if we really need to use notifications, or if the attention screen functionality is not enough (when pressing home keep it on the top). Then maybe we can replace the "OK" button with a "Dismiss" button.
Also, I don't know how this works with a concurrent call yet (this device has no SIM).
Attachment #8467128 - Flags: feedback?(jelee)
QA Whiteboard: [COM=Gaia::SMS] → [COM=Gaia::SMS][2.1-feature-qa+]
Hello Julien, per discussion, the preferred behavior would be:

Receive CMAS message in style 2 -> tap ok (press home can also dismiss the dialog) -> nothing happen on screen (no sound+vibrate+display) -> back to any screen/homescreen/lockscreen -> go to notification tray -> access the message again by tapping on the notification -> message appears again -> tap ok (the original notification stays in tray, and no new notification) -> notification stays in tray until user manually clears it.

Let me know if there's any update on technical part. Thank you :)
Attachment #8467128 - Flags: feedback?(jelee) → feedback+
Due to limited resource, we won't be able to move forward too quickly here. We'll still move forward but it's limited to 1 point of work.
Whiteboard: [tako] → [tako][p=1]
Target Milestone: --- → 2.1 S3 (29aug)
Hey Jenny, Alive,

I tried to implement the "close when pressing home" behavior, and here is what happens:

* we still see the animation before it closes. Since it's managed by the system app, I don't think this can be changed, unless we have a way to tell the system app that the attention screen is not resizable. Which makes me think we can maybe use the "resizable=no" attribute when we open the attention screen. (of course this needs some development in the system app). What do you think Alive? Is it doable?

* Another side effects is that if we receive a call while the cmas alert is displayed, the alert is dismissed (because it's resized, and I think we can't distinguish the cases). We still have the notification though.

I still think we should keep the default attention screen behavior here.

Ni Jenny and Alive for these questions.
Flags: needinfo?(jelee)
Flags: needinfo?(alive)
(In reply to Julien Wajsberg [:julienw] from comment #31)
> Hey Jenny, Alive,
> 
> I tried to implement the "close when pressing home" behavior, and here is
> what happens:
> 
> * we still see the animation before it closes. Since it's managed by the
> system app, I don't think this can be changed, unless we have a way to tell
> the system app that the attention screen is not resizable. Which makes me
> think we can maybe use the "resizable=no" attribute when we open the
> attention screen. (of course this needs some development in the system app).
> What do you think Alive? Is it doable?

I think I managed to have something that looks good. We see the animation (sliding up) but that's all. It looks quite great IMO :)

> 
> * Another side effects is that if we receive a call while the cmas alert is
> displayed, the alert is dismissed (because it's resized, and I think we
> can't distinguish the cases). We still have the notification though.

This still happens though !
Attached file github PR
Hey Michael,

can you have a look to the changes to the System app's notification subsystem? They are the 2 last commits in the pull request. I don't think I'd need to change the system app much more than this.
Attachment #8468530 - Flags: feedback?(mhenretty)
Fang, we need the icons for the notification here, and possibly a design for the message screen itself.

Thanks !
Flags: needinfo?(fshih)
(In reply to Julien Wajsberg [:julienw] from comment #32)

> > 
> > * Another side effects is that if we receive a call while the cmas alert is
> > displayed, the alert is dismissed (because it's resized, and I think we
> > can't distinguish the cases). We still have the notification though.
> 
> This still happens though !

I think this happens because I don't have icons. Alive, here is a log:

E GeckoConsole: [JavaScript Error: "TypeError: manifest.icons is not an object" {file: "app://system.gaiamobile.org/js/attention_screen.js" line: 307}]

I'm adding icons now and I'll see what happens.
(In reply to Julien Wajsberg [:julienw] from comment #35)
> (In reply to Julien Wajsberg [:julienw] from comment #32)
> 
> > > 
> > > * Another side effects is that if we receive a call while the cmas alert is
> > > displayed, the alert is dismissed (because it's resized, and I think we
> > > can't distinguish the cases). We still have the notification though.
> > 
> > This still happens though !
> 
> I think this happens because I don't have icons. Alive, here is a log:
> 
> E GeckoConsole: [JavaScript Error: "TypeError: manifest.icons is not an
> object" {file: "app://system.gaiamobile.org/js/attention_screen.js" line:
> 307}]
> 
> I'm adding icons now and I'll see what happens.

ok, it does not disappear when I'm adding an icon ! The PR is updated with these changes !
Something that Jenny and I discussed together and I haven't done yet: not closing the notification when we click on it, and keep it if present when we click "ok".(In reply to Julien Wajsberg [:julienw] from comment #33)
> Created attachment 8468530 [details] [review]
> github PR
> 
> Hey Michael,
> 
> can you have a look to the changes to the System app's notification
> subsystem? They are the 2 last commits in the pull request. I don't think
> I'd need to change the system app much more than this.

Actually, it'sn ow the 2 first commits ;) It will be easier if their hashes don't change each time I push.
(In reply to Julien Wajsberg [:julienw] from comment #31)
> Hey Jenny, Alive,
> 
> I tried to implement the "close when pressing home" behavior, and here is
> what happens:
> 
> * we still see the animation before it closes. Since it's managed by the
> system app, I don't think this can be changed, unless we have a way to tell
> the system app that the attention screen is not resizable. Which makes me
> think we can maybe use the "resizable=no" attribute when we open the
> attention screen. (of course this needs some development in the system app).
> What do you think Alive? Is it doable?

I think that's do-able.., but we need a bug for that. And since attention screen is tremendously changed in bug 927862,
we should do that after bug 927862 landed. 

> 
> * Another side effects is that if we receive a call while the cmas alert is
> displayed, the alert is dismissed (because it's resized, and I think we
> can't distinguish the cases). We still have the notification though.
> 
> I still think we should keep the default attention screen behavior here.
> 
> Ni Jenny and Alive for these questions.

This is the expected behavior of multiple attention screens.
The new attention screen will show upon current displayed attention screen and the below one will go to background.
I am not sure what you do to close yourselves when pressing home button - IMO you should use visibilitychange event. If so, yes, we cannot distinguish.
Flags: needinfo?(alive)
(In reply to Julien Wajsberg [:julienw] from comment #32)
> (In reply to Julien Wajsberg [:julienw] from comment #31)
> > Hey Jenny, Alive,
> > 
> > I tried to implement the "close when pressing home" behavior, and here is
> > what happens:
> > 
> > * we still see the animation before it closes. Since it's managed by the
> > system app, I don't think this can be changed, unless we have a way to tell
> > the system app that the attention screen is not resizable. Which makes me
> > think we can maybe use the "resizable=no" attribute when we open the
> > attention screen. (of course this needs some development in the system app).
> > What do you think Alive? Is it doable?
> 
> I think I managed to have something that looks good. We see the animation
> (sliding up) but that's all. It looks quite great IMO :)
> 

Exactly..for attention screen there should be no animation except callscreen. Callscreen maintains its own animation and that's something bad so I changed it in bug 927862. Any normal attention screen has no opening/closing animations. They resize right away.
Comment on attachment 8468530 [details] [review]
github PR

I left some comments on the commit: https://github.com/julienw/gaia/commit/a28aae4f217fb8852424fa70af19d6e154809ddf

Overall, I think this approach is workable. I still don't like the idea of making a special 'very-important' list for these notifications, but I guess you would have the same thing with 'fake-notifications' in the system app (although I prefer a hack contained in the system app vs the notification system itself).

Also, I didn't see anything about keeping these notifications silent. Might want to add a list similar to VERY_IMPORTANT_APPS, like SILENT_APPS, and maybe even NO_VIBRATE_APPS. Just a thought.
Attachment #8468530 - Flags: feedback?(mhenretty) → feedback+
(In reply to Michael Henretty [:mhenretty] from comment #40)
> Comment on attachment 8468530 [details] [review]
> github PR
> 
> I left some comments on the commit:
> https://github.com/julienw/gaia/commit/
> a28aae4f217fb8852424fa70af19d6e154809ddf
> 
> Overall, I think this approach is workable. I still don't like the idea of
> making a special 'very-important' list for these notifications, but I guess
> you would have the same thing with 'fake-notifications' in the system app
> (although I prefer a hack contained in the system app vs the notification
> system itself).

The idea was that eventually, when we'll have the full-fledged modes, we'll reuse this directly.

> 
> Also, I didn't see anything about keeping these notifications silent. Might
> want to add a list similar to VERY_IMPORTANT_APPS, like SILENT_APPS, and
> maybe even NO_VIBRATE_APPS. Just a thought.

It's in the other commit ;) https://github.com/julienw/gaia/commit/4befc1a588a29a7f80f4a7bdda5b16418ca5e1ab

Do you prefer that I do a separate list instead of this adhoc check?
Flags: needinfo?(mhenretty)
(In reply to Julien Wajsberg [:julienw] from comment #35)
> 
> I think this happens because I don't have icons. Alive, here is a log:
> 
> E GeckoConsole: [JavaScript Error: "TypeError: manifest.icons is not an
> object" {file: "app://system.gaiamobile.org/js/attention_screen.js" line:
> 307}]
> 

Filed bug 1050289 for this.

(In reply to Alive Kuo [:alive][NEEDINFO!] from comment #38)
> > * we still see the animation before it closes. Since it's managed by the
> > system app, I don't think this can be changed, unless we have a way to tell
> > the system app that the attention screen is not resizable. Which makes me
> > think we can maybe use the "resizable=no" attribute when we open the
> > attention screen. (of course this needs some development in the system app).
> > What do you think Alive? Is it doable?
> 
> I think that's do-able.., but we need a bug for that. And since attention
> screen is tremendously changed in bug 927862,
> we should do that after bug 927862 landed. 

Filed bug 1050288.
(In reply to Julien Wajsberg [:julienw] from comment #41)
> Do you prefer that I do a separate list instead of this adhoc check?

Ah I see now. It's up to you. I personally think a "silent" list would be cleaner, but ad hoc stuff like what we did with email has already been around, so I don't expect you to clean all that up here.
Flags: needinfo?(mhenretty)
Flags: in-moztrap?(ashiue)
QA Contact: ashiue
QA Whiteboard: [COM=Gaia::SMS][2.1-feature-qa+] → [COM=Gaia::SMS]
Whiteboard: [tako][p=1] → [tako][p=1][2.1-feature-qa+]
Depends on: 1051788
Depends on: 1051792
No longer blocks: sms-sprint-2.1S2
Whiteboard: [tako][p=1][2.1-feature-qa+] → [tako][2.1-feature-qa+]
Depends on: 1051793
Depends on: 1051795
Alias: cmas-application
Flags: in-moztrap?(ashiue) → in-moztrap?
QA Contact: ashiue
QA Contact: echang
Flags: in-moztrap? → in-moztrap?(echang)
Depends on: 1053359
Clearing myself as we've reached a conclusion in email. Thanks!
Flags: needinfo?(jelee)
Note: the new Attention Screen implementation is in Bug 927862.
Attached file CMAS_icon.zip
Hi,
Attached the CMAS icons!Thanks!
Flags: needinfo?(fshih)
Hey Fang, as I understand, we use the normal building block design for a "confirm" dialog?
Flags: needinfo?(fshih)
(In reply to Julien Wajsberg [:julienw] from comment #47)
> Hey Fang, as I understand, we use the normal building block design for a
> "confirm" dialog?

Yes, We use the normal building block design! Thanks!
Flags: needinfo?(fshih)
Depends on: 1055994
Assignee: nobody → schung
Flags: in-moztrap?(echang) → in-moztrap-
Confirmed with EM/EPM, and this can be landed before FL.
Depends on: 1060727
No longer depends on: 1060727
Close as fixed since all the key items are addressed in master.
Status: NEW → RESOLVED
Closed: 6 years ago
Resolution: --- → FIXED
Verified User story is landed, emulator test.
Gaia      e7d31f0e9b6b19d9b484eeec8fb980718bc40d79
Gecko     https://hg.mozilla.org/mozilla-central/rev/532b5fb77ba1
BuildID   20140901160203
Version   34.0a1
ro.build.version.incremental=110
ro.build.date=Fri Jun 27 15:57:58 CST 2014
B1TC00011230
Status: RESOLVED → VERIFIED
Depends on: 1067295
Depends on: 1067938
FxOS Sec did a time-boxed security review of the Network Alerts implementation. See https://wiki.mozilla.org/Security/Reviews/B2G/NetworkAlerts for details.

TL;DR: no security issues were found, but it looks like it's lacking broadcast duplication detection.

There's tracking bug 1067295 for the sec review and bug 1067938 for the duplication issue which are both blocking this bug for now.
Resolution: FIXED → INCOMPLETE
Fixing the resolution here - this is marked fixed to indicate that the feature is complete.
Resolution: INCOMPLETE → FIXED
Depends on: 1091751
Component: Gaia::SMS → Gaia::Network Alerts
Depends on: 1091960
Depends on: 1099100
Depends on: 1094589
blocking-b2g: backlog → ---
You need to log in before you can comment on or make changes to this bug.