Closed Bug 991949 Opened 7 years ago Closed 6 years ago

Cell broadcast ETWS messages show undefined

Categories

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

x86
macOS
defect
Not set
normal

Tracking

(feature-b2g:2.0, b2g-v2.0 fixed, b2g-v2.1 fixed)

RESOLVED FIXED
feature-b2g 2.0
Tracking Status
b2g-v2.0 --- fixed
b2g-v2.1 --- fixed

People

(Reporter: mschwart, Assigned: mschwart)

References

Details

(Keywords: late-l10n, Whiteboard: [CR 642865])

Attachments

(2 files, 1 obsolete file)

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
I know we supported cell broadcast messages, but does that include ETWS message type as well?
(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
Okay - I'll set the blocking+ flag then.

Do you know if this is happening on 1.3?
blocking-b2g: 1.4? → 1.4+
Keywords: regression
This is a new feature so yes.
oh in that case, let me send through official triage then.
blocking-b2g: 1.4+ → 1.4?
Keywords: regression
Let me try asking the question a different way.

Is this working correctly on 1.3 right now?
blocking-b2g: 1.4? → 1.4+
Flags: needinfo?(mschwart)
No.
Flags: needinfo?(mschwart)
Seems we need UX to define what texts should be shown in the message body in this case. Flagging in Omega!
Flags: needinfo?(ofeng)
So how many types of messages we will get? Are they "earthquake", "tsunami", "earthquake-tsunami", "test", and "other"?
Flags: needinfo?(ofeng)
(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.
Component: Gaia::Dialer → Gaia::System
Hi Tim,
Looks Gecko is working as expected that ETWS messageID is sent. 
Once Omega defined corresponding messages, can someone from GAIA handles this?
Flags: needinfo?(timdream)
Right. Yet another late feature request.
I will discuss the detail with Omega on Monday.
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.
blocking-b2g: 1.4+ → 1.4?
Flags: needinfo?(timdream) → needinfo?(whuang)
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)
blocking-b2g: 1.4? → ---
Flags: needinfo?(whuang)
Wayne, should we dup the bug or INVALID this bug?
Flags: needinfo?(wchang)
Let's leave this bug open for future contribution of the open source implementation for this feature.
Flags: needinfo?(wchang)
Here is the UX spec. Please see if you have any comments, thanks!
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?
Flags: needinfo?(wchang)
(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.
(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!
(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).
Flags: needinfo?(wchang)
(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.
(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?
Flags: needinfo?(wchang)
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.
Flags: needinfo?(wchang)
(In reply to Bruce Huang [:bhuang] <bhuang@mozilla.com> 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 14 has the link to the confidential bug.
(In reply to Bruce Huang [:bhuang] <bhuang@mozilla.com> 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.
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.
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.
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.
Rik, do you know if cell broadcast ETWS has been implemented before?
Flags: needinfo?(anthony)
In comment #1, you can see the current behaviour that was implemented since the beginning.
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.
Flags: needinfo?(anthony)
No longer depends on: CAF-v2.0-FC-metabug
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.
blocking-b2g: --- → 2.0?
Flags: needinfo?(wchang)
Flags: needinfo?(bhuang)
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.
Flags: needinfo?(wchang)
This doesn't block our own 2.0, we can wait for the partner contribution considering the release market.
Flags: needinfo?(bhuang)
M4, I am assigning this bug to you so you can work on the patch.
Assignee: nobody → mschwart
Flags: needinfo?(mschwart)
Attached file Gaia patch v1 (obsolete) —
Attachment #8432851 - Flags: review?(dale)
Attachment #8432851 - Flags: review?(arthur.chen)
Flags: needinfo?(mschwart)
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.
blocking-b2g: 2.0? → ---
Comment on attachment 8432851 [details] [review]
Gaia patch v1

Redirect the review request to the owner of the system app.
Attachment #8432851 - Flags: review?(arthur.chen) → review?(alive)
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.
Attachment #8432851 - Flags: review?(dale) → feedback+
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.
Attachment #8432851 - Flags: review?(alive) → feedback+
feature-b2g: --- → 2.0
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.
Flags: needinfo?(mschwart)
Attached file Gaia patch v2
Attachment #8432851 - Attachment is obsolete: true
Attachment #8437311 - Flags: review?(timdream)
Attachment #8437311 - Flags: review?(alive)
Requesting uplift to 2.0
blocking-b2g: --- → 2.0?
Flags: needinfo?(mschwart)
(In reply to Michael Schwartz [:m4] from comment #45)
> Requesting uplift to 2.0

Please request the uplift approval with your patch.
blocking-b2g: 2.0? → ---
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.
Attachment #8437311 - Flags: review?(timdream)
Attachment #8437311 - Flags: review?(alive)
Attachment #8437311 - Flags: review+
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!
Attachment #8437311 - Flags: approval-gaia-v2.0?
Whiteboard: [CR 642865] → [CR 642865][checkin-needed]
Keywords: late-l10n
Attachment #8437311 - Flags: approval-gaia-v2.0? → approval-gaia-v2.0+
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 ?
Flags: needinfo?(timdream)
Flags: needinfo?(mschwart)
master: https://github.com/mozilla-b2g/gaia/commit/1dc99a12c211c317c24b77155b28fe84c8b64a8e
2.0: https://github.com/mozilla-b2g/gaia/commit/4f9f3bf87f25cdc865c0371e775b539d1880c123
Status: NEW → RESOLVED
Closed: 6 years ago
Flags: needinfo?(timdream)
Flags: needinfo?(mschwart)
Resolution: --- → FIXED
Whiteboard: [CR 642865][checkin-needed] → [CR 642865]
You need to log in before you can comment on or make changes to this bug.