991949 - Cell broadcast ETWS messages show undefined

Status: RESOLVED FIXED

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

Description

[Michael Schwartz [:m4]]

STR:
# Send a cell broadcast ETWS message with no message body

Observed: a popup is displayed with the message id in the title and the body says "Undefined"

Expected: a canned response should be used based on the ETWS warningType

For example, if we get an ETWS message with: messageId = 4354 and an etws warningType of tsunami then the message body should be something regarding a tsunami.

See 36.523-1 GCF for more info

Comment 1

[Jason Smith [:jsmith]]

I know we supported cell broadcast messages, but does that include ETWS message type as well?

Comment 2

[Michael Schwartz [:m4]]

(In reply to Jason Smith [:jsmith] from comment #1)
> I know we supported cell broadcast messages, but does that include ETWS
> message type as well?

Yes.  http://dxr.mozilla.org/mozilla-central/source/dom/cellbroadcast/interfaces/nsIDOMMozCellBroadcastMessage.idl

Comment 3

[Jason Smith [:jsmith]]

Okay - I'll set the blocking+ flag then.

Do you know if this is happening on 1.3?

Comment 4

[Michael Schwartz [:m4]]

This is a new feature so yes.

Comment 5

[Jason Smith [:jsmith]]

oh in that case, let me send through official triage then.

Comment 6

[Jason Smith [:jsmith]]

Let me try asking the question a different way.

Is this working correctly on 1.3 right now?

Comment 7

[Michael Schwartz [:m4]]

No.

Comment 8

[Hsin-Yi Tsai (she/her) [:hsinyi]]

Seems we need UX to define what texts should be shown in the message body in this case. Flagging in Omega!

Comment 9

[Omega Feng [:Omega] [:馮於懋]]

So how many types of messages we will get? Are they "earthquake", "tsunami", "earthquake-tsunami", "test", and "other"?

Comment 10

[Hsin-Yi Tsai (she/her) [:hsinyi]]

(In reply to Omega Feng [:Omega] from comment #9)
> So how many types of messages we will get? Are they "earthquake", "tsunami",
> "earthquake-tsunami", "test", and "other"?

Yes, they are what we've supported.

Comment 11

[Wesley Huang [:wesley_huang] (EPM) (NI me)]

Hi Tim,
Looks Gecko is working as expected that ETWS messageID is sent. 
Once Omega defined corresponding messages, can someone from GAIA handles this?

Comment 12

[Tim Guan-tin Chien [:timdream] (please needinfo)]

Right. Yet another late feature request.
I will discuss the detail with Omega on Monday.

Comment 13

[Tim Guan-tin Chien [:timdream] (please needinfo)]

Just talk to Omega and I am told that we don't even have a UI spec available yet, for this feature.

This feature wasn't planned on either 1.3 or 1.4. There is no basis to decide to block release on this. The impl the API is not related to Gaia scheduling.

Comment 14

[Wayne Chang [:wchang]]

Given this bug's specific requirements, the Gaia/UI implementation is being handled by partner as part of partner's product. 

It is not part of the FxOS 1.4 scope and partner work is tracked here https://bugzilla.mozilla.org/show_bug.cgi?id=972169  (confidential partner work)

Comment 15

[Tim Guan-tin Chien [:timdream] (please needinfo)]

Wayne, should we dup the bug or INVALID this bug?

Comment 16

[Wayne Chang [:wchang]]

Let's leave this bug open for future contribution of the open source implementation for this feature.

Comment 17

[Omega Feng [:Omega] [:馮於懋]]

Attachment: [1.4 System] Cell Broadcast Message v1.0.pdf

Here is the UX spec. Please see if you have any comments, thanks!

Comment 18

[Preeti Raghunath(:Preeti)]

Wayne,

Do we know if this has to be fixed on Moz code base in 1.4? Is partner going to make this change in Moz code base?

Comment 19

[Michael Schwartz [:m4]]

(In reply to Omega Feng [:Omega] from comment #17)
> Here is the UX spec. Please see if you have any comments, thanks!

Thanks Omega.  How about we go for a more professional sounding message?  Perhaps "Tsunami warning" etc. which is consistent with the Android solution.

(In reply to Preeti Raghunath(:Preeti) from comment #18)

This should be a couple lines of code change max i Gaia plus the l10n strings.  3GPP TS 36.523-1 Section 14.1.2 ETWS Conformance says 'The UE alert the user immediately, using "warning type" value'.  I think we could make the case this is indeed a bug.  Sorry for the confusion.

Comment 20

[Omega Feng [:Omega] [:馮於懋]]

(In reply to Michael Schwartz [:m4] from comment #19)
> Thanks Omega.  How about we go for a more professional sounding message? 
> Perhaps "Tsunami warning" etc. which is consistent with the Android solution.

Thanks for your suggestion, so they will be:
Earthquake warning!
Tsunami warning!
Earthquake-tsunami warning!
Alert system is being tested.
Emergency warning!

They should be better. Let me know if you have any other comments. Thanks!

Comment 21

[Wayne Chang [:wchang]]

(In reply to Preeti Raghunath(:Preeti) from comment #18)
> Wayne,
> 
> Do we know if this has to be fixed on Moz code base in 1.4? Is partner going
> to make this change in Moz code base?

Partner's fix is not landing in 1.4, they may contribute it but that is not happening in the current of next release (probably later, if by then we still dont have a open source implementation).

Comment 22

[Michael Schwartz [:m4]]

(In reply to Omega Feng [:Omega] from comment #20)
> They should be better. Let me know if you have any other comments. Thanks!

How about we ditch the exclamation marks so it looks less like spam and doesn't implicitly say 'panic'?  Other than that, looks good.

Comment 23

[Anshul]

(In reply to Wayne Chang [:wchang] from comment #21)
> (In reply to Preeti Raghunath(:Preeti) from comment #18)
> > Wayne,
> > 
> > Do we know if this has to be fixed on Moz code base in 1.4? Is partner going
> > to make this change in Moz code base?
> 
> Partner's fix is not landing in 1.4, they may contribute it but that is not
> happening in the current of next release (probably later, if by then we
> still dont have a open source implementation).
Wayne, are you implying that this feature needs to be implemented by partners? This feature is to comply with the GCF spec and therefore not a customization so why is this being pushed to partners?

Comment 24

[Bruce Huang [:bhuang] (inactive)]

This is not in 1.4 scope.  Since a partner is already working on this feature, we can take the contribution when it's available instead of duplicating the work in this bug.

Comment 25

[Michael Schwartz [:m4]]

(In reply to Bruce Huang [:bhuang] <[e-mail]> from comment #24)
> This is not in 1.4 scope.

What is not in 1.4 scope?  This is currently a broken feature.

> Since a partner is already working on this
> feature, we can take the contribution when it's available instead of
> duplicating the work in this bug.

Which partner?  Can we assign this bug to that partner or create a confidential bug for tracking?

Comment 26

[Bruce Huang [:bhuang] (inactive)]

Comment 14 has the link to the confidential bug.

Comment 27

[Michael Schwartz [:m4]]

(In reply to Bruce Huang [:bhuang] <[e-mail]> from comment #26)
> Comment 14 has the link to the confidential bug.

That bug is different than this one: this one is about our popup for ETWS messages being broken; that one is about enabling a particular range of messages.

Comment 28

[chris hofmann]

if this is approved for 1.3/1.4 please mark late-l10n and provided good estimates for when final strings will be landed, and lets get clear about where those strings will land, and who will do the localization.  

We are trying to schedule final localization work for 1.4 and need answers to these questions before we can do that.

Comment 29

[Wesley Huang [:wesley_huang] (EPM) (NI me)]

Per discussion today with Anshul, we'll leave this open either for contribution or Moz to do it in the future. Eventually it can be part of mozilla codebase but doesn't block 1.4CS.

Comment 30

[chris hofmann]

Does this need legal/liability review?  If I'm reading these articles right and the ETWS is part of  the regulations for Commercial Mobile Alert System (CMAS), also known as Wireless Emergency Alerts (WEA) it may indicate there might be requirements for advising every subscriber, both new and existing, prominently and in plain language, of the circumstances under which E911 service may not be available. At least in the US.

http://en.wikipedia.org/wiki/Commercial_Mobile_Alert_System and 

http://www.ecfr.gov/cgi-bin/text-idx?c=ecfr;sid=9c27d21733308683e40e9a6ede5d813d;rgn=div5;view=text;node=47%3A1.0.1.1.10;idno=47;cc=ecfr

Under a reasonable interpretation receiving a  "See 36.523-1 GCF for more info" message on a phone might not be adequate support for early warning tsunami alerts for example.

and we might need to  ...Obtain and keep a record of affirmative acknowledgement by every subscriber, both new and existing, of having received and understood the advisory...

Does anyone fully understand the connection between ETWS and CMAS?

This would be for shipping phones within the US like we might do with the Flame.  Then there research for similar regulations in other countries where the phones might ship.  That's probably mostly vendor liability, but Mozilla might share in this as well if we are interpreted as the software provider.

Comment 31

[Arthur Chen [:arthurcc][inactive after 6/30]]

Rik, do you know if cell broadcast ETWS has been implemented before?

Comment 32

[Michael Schwartz [:m4]]

In comment #1, you can see the current behaviour that was implemented since the beginning.

Comment 33

[Anthony Ricaud (:rik)]

Arthur: I have never worked on Cell Broadcast things. I know we have something called like that, I have no idea if this includes ETWS.

Comment 34

[Wesley Huang [:wesley_huang] (EPM) (NI me)]

Nominate 2.0? per comment 30 and CAF requests this to be in 2.0.
I know weeks ago the conclusion is waiting for partner contribution.
NI? Wayne and Bruce to see if that's still the plan, or we should consider prioritzing this in 2.0.

Comment 35

[Wayne Chang [:wchang]]

If any partner is working on this they're working at their own pace for their product, and contribution will depend on that, not our release schedule. 

So if we want to block 2.0 on this, I wouldn't count on a partner delivery and we should handle this with our own resource.

Comment 36

[Bruce Huang [:bhuang] (inactive)]

This doesn't block our own 2.0, we can wait for the partner contribution considering the release market.

Comment 37

[Anshul]

M4, I am assigning this bug to you so you can work on the patch.

Comment 38

[Michael Schwartz [:m4]]

Attachment: Gaia patch v1

Comment 39

[bhavana bajaj [:bajaj]]

Clearing the blocking flag here per Bruce's comment# 36.

:m4, thanks for grabbing this bug. If for any reason, this misses landing on master by FL, we'll consider uplift.

Comment 40

[Arthur Chen [:arthurcc][inactive after 6/30]]

Comment on attachment 8432851 [details] [review]
Gaia patch v1

Redirect the review request to the owner of the system app.

Comment 41

[Dale Harvey (:daleharvey)]

Comment on attachment 8432851 [details] [review]
Gaia patch v1

I think alive is better to review this, I only touched cell broadcast a long time ago, I think we would prefer to remove the defensive programming on that conditional, but will defer review to alive.

Comment 42

[Tim Guan-tin Chien [:timdream] (please needinfo)]

Comment on attachment 8432851 [details] [review]
Gaia patch v1

Stealing review.. m4, please address the comment I made on Github and request re-review. Dale, thanks for pointing that out.

Comment 43

[bhavana bajaj [:bajaj]]

NI :m4 to get this landed on 2.0. :m4, If this misses the boat by merge tomorrow, please seek uplift asap. We can land on the branch depending on the risk involved.

Comment 44

[Michael Schwartz [:m4]]

Attachment: Gaia patch v2

Comment 45

[Michael Schwartz [:m4]]

Requesting uplift to 2.0

Comment 46

[Gregor Wagner [:gwagner]]

(In reply to Michael Schwartz [:m4] from comment #45)
> Requesting uplift to 2.0

Please request the uplift approval with your patch.

Comment 47

[Tim Guan-tin Chien [:timdream] (please needinfo)]

Comment on attachment 8437311 [details] [review]
Gaia patch v2

I was going to ask you to add a unit test to prevent this from regressed however I realized there wasn't a unit test script for this file at first place! Given the fact I am r+'ing this patch without requiring a test, although it is still preferable if you could file a bug to add the tests, and protect your work here.

Comment 48

[Michael Schwartz [:m4]]

Thanks Tim.  Filed https://bugzilla.mozilla.org/show_bug.cgi?id=1024187

Comment 49

[Michael Schwartz [:m4]]

Comment on attachment 8437311 [details] [review]
Gaia patch v2

Please uplift to 2.0

[Testing completed]: Ran manual tests for many of the different types of messages
[Risk to taking this patch] (and alternatives if risky): It affects the message content when empty so risk should be very low.
[String changes made]: New strings were added:
 cb-etws-warningType-earthquake=Earthquake warning!
 cb-etws-warningType-tsunami=Tsunami warning!
 cb-etws-warningType-earthquake-tsunami=Earthquake-tsunami warning!
 cb-etws-warningType-test=Alert system is being tested.
 cb-etws-warningType-other=Emergency warning!

Comment 50

[bhavana bajaj [:bajaj]]

tim/:m2, Ryanvm is out until MOnday and we cannot leave this not checking-in until then due to string changes here, so can either of you please help take care of the landings here ?

Comment 51

[Tim Guan-tin Chien [:timdream] (please needinfo)]

master: https://github.com/mozilla-b2g/gaia/commit/1dc99a12c211c317c24b77155b28fe84c8b64a8e
2.0: https://github.com/mozilla-b2g/gaia/commit/4f9f3bf87f25cdc865c0371e775b539d1880c123