Closed
Bug 1026685
(cmas-application)
Opened 10 years ago
Closed 10 years ago
CMAS Alert channel support
Categories
(Firefox OS Graveyard :: Gaia::Network Alerts, defect)
Tracking
(feature-b2g:2.1, tracking-b2g:backlog)
VERIFIED
FIXED
2.1 S3 (29aug)
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)
(deleted),
application/pdf
|
Details | |
(deleted),
application/pdf
|
Details | |
(deleted),
application/vnd.openxmlformats-officedocument.wordprocessingml.document
|
Details | |
(deleted),
application/pdf
|
Details | |
(deleted),
video/webm
|
jelee
:
feedback+
|
Details |
(deleted),
text/x-github-pull-request
|
mikehenrty
:
feedback+
|
Details |
(deleted),
application/zip
|
Details |
No description provided.
Reporter | ||
Comment 1•10 years ago
|
||
Reporter | ||
Comment 2•10 years ago
|
||
Reporter | ||
Comment 3•10 years ago
|
||
Reporter | ||
Updated•10 years ago
|
blocking-b2g: --- → backlog
feature-b2g: --- → 2.1
User Story: (updated)
Keywords: feature
Whiteboard: [tako]
Comment 5•10 years ago
|
||
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)
Updated•10 years ago
|
QA Whiteboard: [COM=Gaia::SMS]
Updated•10 years ago
|
Comment 10•10 years ago
|
||
(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.
Comment 11•10 years ago
|
||
(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)
Reporter | ||
Comment 12•10 years ago
|
||
correct. this is the final requirement
Flags: needinfo?(wmathanaraj)
Comment 13•10 years ago
|
||
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
Comment 14•10 years ago
|
||
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
Comment 15•10 years ago
|
||
(In reply to Michael Schwartz [:m4] from comment #14) Hi Michael, yes newest should be displayed first. Thanks for pointing that out!
Updated•10 years ago
|
Comment 16•10 years ago
|
||
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.
Comment 17•10 years ago
|
||
(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).
Comment 18•10 years ago
|
||
`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?
Comment 20•10 years ago
|
||
@Vicamo is there any concern for the CMAS property naming?
Flags: needinfo?(vyang)
Comment 21•10 years ago
|
||
(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)
Comment 22•10 years ago
|
||
ok, thanks for clarification :) Since it's not related to gecko, I'd like to take 'cmas.enabled' as settings key.
Comment 24•10 years ago
|
||
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)
Comment 25•10 years ago
|
||
(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)
Comment 26•10 years ago
|
||
(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 :)
Comment 27•10 years ago
|
||
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.
Comment 28•10 years ago
|
||
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)
Updated•10 years ago
|
QA Whiteboard: [COM=Gaia::SMS] → [COM=Gaia::SMS][2.1-feature-qa+]
Comment 29•10 years ago
|
||
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+
Comment 30•10 years ago
|
||
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.
Blocks: sms-sprint-2.1S2
Whiteboard: [tako] → [tako][p=1]
Updated•10 years ago
|
Target Milestone: --- → 2.1 S3 (29aug)
Comment 31•10 years ago
|
||
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)
Comment 32•10 years ago
|
||
(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 !
Comment 33•10 years ago
|
||
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)
Comment 34•10 years ago
|
||
Fang, we need the icons for the notification here, and possibly a design for the message screen itself. Thanks !
Flags: needinfo?(fshih)
Comment 35•10 years ago
|
||
(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.
Comment 36•10 years ago
|
||
(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 !
Comment 37•10 years ago
|
||
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] > 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.
Comment 38•10 years ago
|
||
(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)
Comment 39•10 years ago
|
||
(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 40•10 years ago
|
||
Comment on attachment 8468530 [details] 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+
Comment 41•10 years ago
|
||
(In reply to Michael Henretty [:mhenretty] from comment #40) > Comment on attachment 8468530 [details] > 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)
Comment 42•10 years ago
|
||
(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.
Comment 43•10 years ago
|
||
(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)
Updated•10 years ago
|
Flags: in-moztrap?(ashiue)
Updated•10 years ago
|
QA Contact: ashiue
Updated•10 years ago
|
QA Whiteboard: [COM=Gaia::SMS][2.1-feature-qa+] → [COM=Gaia::SMS]
Whiteboard: [tako][p=1] → [tako][p=1][2.1-feature-qa+]
Updated•10 years ago
|
No longer blocks: sms-sprint-2.1S2
Whiteboard: [tako][p=1][2.1-feature-qa+] → [tako][2.1-feature-qa+]
Updated•10 years ago
|
Alias: cmas-application
Updated•10 years ago
|
Flags: in-moztrap?(ashiue) → in-moztrap?
QA Contact: ashiue
Updated•10 years ago
|
QA Contact: echang
Updated•10 years ago
|
Flags: in-moztrap? → in-moztrap?(echang)
Comment 44•10 years ago
|
||
Clearing myself as we've reached a conclusion in email. Thanks!
Flags: needinfo?(jelee)
Comment 47•10 years ago
|
||
Hey Fang, as I understand, we use the normal building block design for a "confirm" dialog?
Flags: needinfo?(fshih)
Comment 48•10 years ago
|
||
(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)
Updated•10 years ago
|
Assignee: nobody → schung
Updated•10 years ago
|
Flags: in-moztrap?(echang) → in-moztrap-
Assignee | ||
Comment 50•10 years ago
|
||
Close as fixed since all the key items are addressed in master.
Status: NEW → RESOLVED
Closed: 10 years ago
Resolution: --- → FIXED
Comment 51•10 years ago
|
||
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
Updated•10 years ago
|
Status: RESOLVED → VERIFIED
Comment 52•10 years ago
|
||
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.
Updated•10 years ago
|
Resolution: FIXED → INCOMPLETE
Comment 53•10 years ago
|
||
Fixing the resolution here - this is marked fixed to indicate that the feature is complete.
Resolution: INCOMPLETE → FIXED
Updated•10 years ago
|
Component: Gaia::SMS → Gaia::Network Alerts
Updated•10 years ago
|
blocking-b2g: backlog → ---
tracking-b2g:
--- → backlog
You need to log in
before you can comment on or make changes to this bug.
Description
•