Closed Bug 853703 Opened 11 years ago Closed 6 years ago

[GPS] Support SUPL NI case

Categories

(Firefox OS Graveyard :: General, defect)

All
Gonk (Firefox OS)
defect
Not set
normal

Tracking

(feature-b2g:2.2r+, b2g-v2.2r fixed)

RESOLVED WONTFIX
feature-b2g 2.2r+
Tracking Status
b2g-v2.2r --- fixed

People

(Reporter: leo.bugzilla.gecko, Assigned: alchen)

References

Details

(Whiteboard: [caf priority: p2][CR 927436])

User Story

As a FxOS user, I want to be notified of a SUPL Network Initiated request for my location that gives me the ability to approve or cancel it, so that I can control my location privacy.

As an Operator, I want to SUPL notify-verify call flow to be supported on my devices, so that I can deploy network location services in compliance with specs which mandate ni notify-verify call flow.

Attachments

(2 files, 7 obsolete files)

Dear Mozilla team 

There is not implementation SUPL NI client in FFOS.
So, We do not verify SUPL NI case(SI case is clear).

We request implementation of NI client interface in FFOS.

QCT recommend,
"FF should implement NI client to notify user and obtain user response for A-GPS sessions.(FYI, in android case, Google has implemented NI client.) As far as I know, your team has contact point for FF. Please request it to FF. Then, FF may will work with QC HLOS team for it."

Thanks
We don't have any comment for a week.
We hope we can look forward to hearing from your team soon.

Thanks
We don't have any comment for a week.
We hope we can look forward to hearing from your team soon.

Thanks
Joe, could you clarify the issue here? Do we want to implement NI? Bug 854834 is related.
Hi Kan-Ru -

Since TCL is asking SUPL NI again now, just wondering if we put SUPL NI into 1.4(or later)backlog?
Flags: needinfo?(kanru)
Flags: needinfo?(kanru) → needinfo?(kchen)
Ken?
Flags: needinfo?(kchen) → needinfo?(kchang)
(In reply to Kan-Ru Chen [:kanru] from comment #5)
> Ken?
It triggers SUPL by sending GPS WAP Push from network. In current design, Gecko will send all types WAP push to Gaia. But the problem is whether Gaia handle the GPS WAP Push message. I wonder if this is a feature of comms app/system app.
Flags: needinfo?(kchang) → needinfo?(wmathanaraj)
Flags: needinfo?(bhuang)
Hi Ken -

One follow up question about this SUPL business, i got the following information from TCL:

"because we had agreed with Mozilla that LF 1.2 and newer devices would use GTP and NOT SUPL.
In another word, LF 1.2 don't support SUPL.

So we disabled AGPS"

Is the above statements from QCT true? or we still support aGPS with GTP in 1.2 and later release?

Thanks for your help
Flags: needinfo?(kchang)
Kanru, do you have any comment?
Flags: needinfo?(kchang) → needinfo?(kchen)
I dont think we have implemented anything in Comms to handle GPS wap push messages.
Flags: needinfo?(wmathanaraj)
So the information of using GTP might be misleading.

To implement NI we might need to implement receiving SUPL INIT message via WAP Push or SIP Push or MT SMS or UDP/IP. I think WAP Push is minimum set we should support. This involves showing a notification or dialog when the network initiated a location lookup which may or may not require UI change. I'll study it then talk to people.
Flags: needinfo?(kchen)
Flags: needinfo?(bhuang)
Will this be added for v1.4 ?
GTP is global terrestrial positioning. We are mixing two topics in this discussion:

a) From LF 1.2, Network Position Provider source has switched from SUPL to GTP. This applies to Mobile originated session only

b) For NI (Network Initiated) session, a) does not apply. It is a service operator can offer. Nothing needs to be implemented for SMS NI message; SMS NI triggering has been implemented under the hood on the modem (Low Power Processor). What is missing for NI on FFOS is an UI: When position engine receives a NI session request, a popup window has to be shown to user, so user can accept or reject the NI session request(or in some case, a notification only message to user), and user's response has to be sent back to modem through GonkGpsLocationProvider API. Similar implementation can be found on Android: the HAL API for Android Framework to hook up is defined in hardware/libhardware/include/hardware/gps.h: GpsNiInterface/GpsNiCallbacks/GpsNiNotification. UI implementation can be found in frameworks/base/location/java/com/android/internal/location/GpsNetInitiatedHandler.java. it is triggered through reportNiNotification() in frameworks/base/services/java/com/android/server/location/GpsLocationProvider.java

Also Notice in frameworks/base/services/java/com/android/server/location/GpsLocationProvider.java, there is a BroadcastReceiver() listening for DATA_SMS_RECEIVED_ACTION, WAP_PUSH_RECEIVED_ACTION. They are only for AP based NI solution, it will cause higher power usage. For architecture with Modem based Low Power Location engine solution, they shouldn't be added because SMS/WAP are captured on modem (Low Power); adding these on AP will cause unnecessary power usage.
Thanks for your explanation Stephen, I think I get a rough idea but still a little bit confused about the AGPS support...Could you also kindly help to comment on comment#7, where our partner questioned that if AGPS is no longer support since LF 1.2?

Thanks

Vance
Flags: needinfo?(stephenl)
Comment #7 is true for Mobile Originated Session (MO). It does not apply to Mobile Terminated Session (MT). However, I am not aware of any carrier requirement for MT at the moment.
Flags: needinfo?(stephenl)
OS: Windows XP → Gonk (Firefox OS)
Hardware: x86 → All
Summary: [GPS] Support SUPL NI case, It is not implementation → [GPS] Support SUPL NI case
With US launches being planned, partner is asking for support of SUPL NI notify/verify. Jamin, can you please evaluate adding support for User input for the NI notify verify use case.
Flags: needinfo?(jaliu)
Hi Ravi,
To support SUPL NI (including notify/verify), the task can be divided into 3 parts.

1) Implements the handler of GpsNiCallbacks and other SUPL NI related functions in Gecko.
2) Adds a dialog for user approval in Gaia.
3) In-house verification and GCF certivication.

== 1) the Gecko part ==
As far as I know, the first part might need some help from RIL team since it have to access WapPush message of RIL worker.  I wouldn't say I'm qualified to evaluate the effort, however, I guess it would take about 2.5 weeks to implement the Gecko part.

== 2) the Gaia part ==
Hi Evelyn,
Would you please to help us to evaluate the effort of this part ?

== 3) verification ==
It would be hard to verify SUPL NI without partners' help.
I suggest we work closely with carrier and vendor since they have much more experience on GCF certification. (And we need they to initiate SUPL requests from their server.) 
I can't really evaluate this part without communicating with our partners.

Ravi
Would you mind to let me know whether this task is under a tight schedule ?
Which branch is the first priority ? m-c, v2.2 or red-tai ? 

Regards, :)
Jamin
Flags: needinfo?(rdandu)
Flags: needinfo?(jaliu)
Flags: needinfo?(ehung)
Jamin, this is needed 2.2 and red-tai. You don't need to worry about processing the ni message from SUPL server (referred to as WapPush in this bug). The processing happens in the GPS HW/modem, so FxOS needs to do is support the notify-verify user input.
Flags: needinfo?(rdandu)
(In reply to rdandu from comment #17)
> Jamin, this is needed 2.2 and red-tai. You don't need to worry about
> processing the ni message from SUPL server (referred to as WapPush in this
> bug). The processing happens in the GPS HW/modem, so FxOS needs to do is
> support the notify-verify user input.

Thank you for your comment.
I understand it an important feature for our partner. 
Device team will discuss the detailed schedule to meet the requirement from our partner.
User Story: (updated)
Per offline discussion, the effort of Gaia part seems to be displaying a pop-up in System app for notifying users and record their decision. It won't be hard and may just take 1 week for implementation and test.
Flags: needinfo?(ehung)
Evelyn,

The QC location module is not part of libuxl.so, we will need clearly defined gecko interfaces to communicate between Gaia and the QC location module.
I think we could present the request as a real permission prompt; that way the effort of Gaia side is at minimum.
Hi there,

I've made a very early prototype of Gaia side: https://github.com/luke-chang/gaia/commit/e6ba9b1fa38cb374fdd1f6fde21e6b8656f723ac

I assume the communication between Gaia and Gecko is using mozChromeEvent/mozContentEvent and implemented the notification and ModalDialog for notify and verify scenarios respectively.

Hope it'll be helpful.
Hi All,

I understand the communication between Gecko/Gaia is via mozChromeEvent/mozContentEvent.

Please note that QC location component is not part of libxul.so, it is a separate C++ XPCOM component that communicates with Gecko via XPCOM interfacee. Will these Gecko calls be accessible directly from native code i.e. c++.
(In reply to Bhavna Sharma from comment #23)
> Please note that QC location component is not part of libxul.so, it is a
> separate C++ XPCOM component that communicates with Gecko via XPCOM
> interfacee. Will these Gecko calls be accessible directly from native code
> i.e. c++.
Hi Bhavna,

Thank you for the information.
The most of Gecko changes will be made at GonkGPSGeolocationProvider which uses C++ as the language.

Although the whole process would involve to <gecko>/b2g/chrome/content/shell.js and javascript files from Gaia, the trigger point of the send/receive process will still remain in GonkGPSGeolocationProvider.

As far as I know, QC will replace mozilla's GonkGPSGeolocationProvider by its own version.
It do need some extra effort for QC to pick the change to QC/TCL's branch, however, I believe it won't be a big problem.

The patch of SUPL NI will be updated on this bug, please feel free to give some feedbacks if you notice something will be issue for QC/TCL Integration.

Thank you. :)
Here is the gecko implementation for the support of supl ni.

Gecko use chrome event and a settings key to communicate with gaia.
Luke will upload the gaia patch corresponding to this design.
Assignee: nobody → alchen
This is the Gaia part based on Alphan's implementation in comment 25. Please let me know if there are any problems.
We will review the patch set and get back asap.
Hi Alphan,

GpsNiNotification has a few more fields that are required by Gaia/Gecko to handle

/** Represents an NI request */
typedef struct {
    /** set to sizeof(GpsNiNotification) */
    size_t          size;

    /**
     * An ID generated by HAL to associate NI notifications and UI
     * responses
     */
    int             notification_id;

    /**
     * An NI type used to distinguish different categories of NI
     * events, such as GPS_NI_TYPE_VOICE, GPS_NI_TYPE_UMTS_SUPL, ...
     */
    GpsNiType       ni_type;

    /**
     * Notification/verification options, combinations of GpsNiNotifyFlags constants
     */
    GpsNiNotifyFlags notify_flags;

    /**
     * Timeout period to wait for user response.
     * Set to 0 for no time out limit.
     */
    int             timeout;

    /**
     * Default response when time out.
     */
    GpsUserResponseType default_response;

    /**
     * Requestor ID
     */
    char            requestor_id[GPS_NI_SHORT_STRING_MAXLEN];

    /**
     * Notification message. It can also be used to store client_id in some cases
     */
    char            text[GPS_NI_LONG_STRING_MAXLEN];

    /**
     * Client name decoding scheme
     */
    GpsNiEncodingType requestor_id_encoding;

    /**
     * Client name decoding scheme
     */
    GpsNiEncodingType text_encoding;

    /**
     * A pointer to extra data. Format:
     * key_1 = value_1
     * key_2 = value_2
     */
    char           extras[GPS_NI_LONG_STRING_MAXLEN];

} GpsNiNotification;

1. requestor_id and text is received from the modem and needs to be displayed to the user in the notification message. Both the above fields are encoded and need to be decoded as per the GpsNiEncodingType.

2. There is also a timeout and default response field that the Gaia layer needs to handle. Gaia will need to respond back if default response if the user does not respon within teh given time.

How do we pass the above fields ?
All the above fields are received from network and are carrier specified.
(In reply to Bhavna Sharma from comment #28)
Hi Bhavna,
Thank you for you time to review the patch.

> 1. requestor_id and text is received from the modem and needs to be
> displayed to the user in the notification message. Both the above fields are
> encoded and need to be decoded as per the GpsNiEncodingType.

Per offline discussion with Alphan, we think the requestor ID is not a necessary information for users. It's more reasonable to me to print the requestor_id as a log to developer rather than message to user.

On the other hand, notification message is meaningful for user. However, it's hard to localize strings appearing in different language if we use 'GpsNiNotification:text' at runtime. Alphan will consult with our UX designer to find a right way to display the notification message.

As far as I know, SULP test spec doesn't require to display requestor ID and specified message.
The test case SUPL-1.0-con-271 (#Attachment 8636376 [details]) only requires for "some form of notification"

> 2. There is also a timeout and default response field that the Gaia layer
> needs to handle. Gaia will need to respond back if default response if the
> user does not respon within teh given time.

It makes sense to me to add a default response for timeout handling.
Alphan is going to handle the [timeout/default response] process on the next patch.

Thank Bhavna and Alphan for their time.
Below are the wording recommendation from UX:

NI Notify:
Dialog title: Location Request
Dialog content: Your location is being transmitted to the operator.

NI Verify:
Dialog title: Location Request
Dialog content: The operator is requesting your location. Do you want to provide your location info to the operator?

Please feel free to ask me if you have any concerns. Thanks.
In this patch, I add the mechanism for the handling of timeout case.
If user doesn't have response to the verification for several seconds(notification->timeout), gecko will send a specific chrome event to gaia and reply default response to HAL.
When gaia get this chrome event, it will close the corresponding verification window.
Attachment #8633919 - Attachment is obsolete: true
As Alphan mentioned, this is the corresponding patch of Gaia part.

Also, the workflow of the verification case is improved when screen is locked or turned off.
Attachment #8633950 - Attachment is obsolete: true
Hi Garvan,
I would like to invite you to do this review.
It is a patch which support SUPL NI requirement.

In this patch,
1. We use chrome event to sent SUPL NI request to Gaia. (Gaia will do corresponding behavior when receiving different chrome event.)
2. Gecko will monitor the settings key to know the user choice of SUPL NI verification.
3. We also introduce the timeout mechanism by sending a unique chrome event to let Gaia close specific window.
Attachment #8639190 - Attachment is obsolete: true
Attachment #8646745 - Flags: review?(gkeeley)
Attachment #8646745 - Flags: superreview?(gkeeley)
Comment on attachment 8646745 [details] [diff] [review]
[v2.2-GECKO part] Bug 853703- support SUPL NI

Jamin is more familiar with NI SUPL so I'll ask he do the review. I can super review after him as a module peer.
Attachment #8646745 - Flags: review?(gkeeley) → review?(jaliu)
Comment on attachment 8646745 [details] [diff] [review]
[v2.2-GECKO part] Bug 853703- support SUPL NI

Review of attachment 8646745 [details] [diff] [review]:
-----------------------------------------------------------------

::: dom/system/gonk/GonkGPSGeolocationProvider.cpp
@@ +236,5 @@
> +    }
> +    return false;
> +  }
> +
> +  nsCString str = nsPrintfCString("%d", id);

This patchset does not pass notification message still right ?
Is there an ETA for it ?
Comment on attachment 8646745 [details] [diff] [review]
[v2.2-GECKO part] Bug 853703- support SUPL NI

Review of attachment 8646745 [details] [diff] [review]:
-----------------------------------------------------------------

r=me with comment addressed.

Thank Alphan for the effort. :)


Please use capital letter S for 'S'upport in the commit message.

::: dom/system/gonk/GonkGPSGeolocationProvider.cpp
@@ +49,5 @@
>  #define AGPS_HAVE_DUAL_APN
>  #endif
>  
>  #define FLUSH_AIDE_DATA 0
> +#define SUPL_NI_NOTIFY "subl-ni-notify"

Please add one space here to aligned with line 54.

@@ +52,5 @@
>  #define FLUSH_AIDE_DATA 0
> +#define SUPL_NI_NOTIFY "subl-ni-notify"
> +#define SUPL_NI_VERIFY  "subl-ni-verify"
> +#define SUPL_NI_VERIFY_TIMEOUT  "subl-ni-verify-timeout"
> +#define GPS_NI_NEED_TIMEOUT 0x999

1. Please leave a comment to explain this macro.
2. Would you consider to define this macro as 0x0008, 0x0016 or 0x0032 ... ?
   Or would you consider to use 0xFFFF or 0x00FF instead of 0x999 ?

@@ +251,5 @@
> +
> +void
> +GonkGPSGeolocationProvider::GPSNiNotifyCallback(GpsNiNotification *notification)
> +{
> +  int id = notification->notification_id;

NI notification message is mandatory for supporting SUPL 2.0.
Since we decide not to display of NI notification message in this patch, I suggest you create a follow up bug to address this feature to remind us to fix it in future.

@@ +264,5 @@
> +    GonkGPSGeolocationProvider::GetSingleton();
> +
> +  if(!provider->SendChromeEvent(id, flags)) {
> +    nsContentUtils::LogMessageToConsole(
> +      "SendChromeEvent Failed(id:%d, flags:%d)", id, flags);

Since you use "%x" to print flag at line 259, I think you should use %x instead %d here, right?

@@ +284,5 @@
> +        nsRefPtr<GonkGPSGeolocationProvider> provider =
> +          GonkGPSGeolocationProvider::GetSingleton();
> +        if (!provider->SendChromeEvent(mId, GPS_NI_NEED_TIMEOUT)) {
> +          nsContentUtils::LogMessageToConsole(
> +            "SendChromeEvent Failed(id:%d, flags:%d", mId, GPS_NI_NEED_TIMEOUT);

Ditto

@@ +1144,5 @@
>        nsContentUtils::LogMessageToConsole("geo: received mozsettings-changed: logging\n");
>        gDebug_isLoggingEnabled =
>          setting.mValue.isBoolean() ? setting.mValue.toBoolean() : false;
>        return NS_OK;
> +    } else if (setting.mKey.EqualsASCII(kSettingSuplVerificationChoice)) {

It would be great if you leave a comment here or at line 70 to explain the mechanism you are using to communicate with Gaia.

@@ +1153,5 @@
> +      if (id >= 0) {
> +        provider->SetNiResponse(id, GPS_NI_RESPONSE_ACCEPT);
> +        receivedIDs.AppendElement(id);
> +      } else {
> +        provider->SetNiResponse(id*-1, GPS_NI_RESPONSE_DENY);

Would you mind to leave comments here to explain the meaning of negative ID.
Attachment #8646745 - Flags: review?(jaliu) → review+
Hi there,

I've filed bug 1195602 for tracking the Gaia patch.
Comment on attachment 8649085 [details] [review]
[gaia] luke-chang:1195602_v2.2_supl_ni > mozilla-b2g:v2.2

Wrong pull request. Sorry.
Attachment #8649085 - Attachment is obsolete: true
(In reply to Bhavna Sharma from comment #37)
> 
> This patchset does not pass notification message still right ?
> Is there an ETA for it ?

Hi Bhavna,
I am afraid that you are right.
In this patch, we include timeout mechanism without notification message.

There are two reasons that we don't include it in this patch.
1. We cannot handle GSM_DEFAULT encoding right now.
   It would like extra effort to decode this format.
2. By checking ETS-SUPL-V1.0, Requestor ID and Client name should be a optional features in SUPL 1.0.
   SUPL-1.0-con-279 – Requestor ID and Client Name [Includes optional features]
So we decide to land current patch into our 2.2 codebase first.

Hi Wesley,
could you update the future plan as well?
Flags: needinfo?(wehuang)
Hi Garvan,
I refined the patch based on Jamin's review.
Here is the latest one.
Thanks.
Attachment #8646745 - Attachment is obsolete: true
Attachment #8646745 - Flags: superreview?(gkeeley)
Attachment #8649166 - Flags: review?(gkeeley)
Comment on attachment 8649166 [details] [diff] [review]
[v2.2-GECKO part] Bug 853703- support SUPL NI. r=jaliu

Review of attachment 8649166 [details] [diff] [review]:
-----------------------------------------------------------------

Let's leave Jamin as the reviewer, he is best acquainted with NI-SUPL-AGPS and covered most of the important points.

::: dom/system/gonk/GonkGPSGeolocationProvider.cpp
@@ +49,5 @@
>  #define AGPS_HAVE_DUAL_APN
>  #endif
>  
>  #define FLUSH_AIDE_DATA 0
> +#define SUPL_NI_NOTIFY  "subl-ni-notify"

supl

@@ +50,5 @@
>  #endif
>  
>  #define FLUSH_AIDE_DATA 0
> +#define SUPL_NI_NOTIFY  "subl-ni-notify"
> +#define SUPL_NI_VERIFY  "subl-ni-verify"

supl

@@ +51,5 @@
>  
>  #define FLUSH_AIDE_DATA 0
> +#define SUPL_NI_NOTIFY  "subl-ni-notify"
> +#define SUPL_NI_VERIFY  "subl-ni-verify"
> +#define SUPL_NI_VERIFY_TIMEOUT  "subl-ni-verify-timeout"

supl

@@ +85,5 @@
>  
>  /* static */ GonkGPSGeolocationProvider* GonkGPSGeolocationProvider::sSingleton = nullptr;
>  GpsCallbacks GonkGPSGeolocationProvider::mCallbacks;
> +GpsNiCallbacks GonkGPSGeolocationProvider::mGPSNiCallbacks;
> +static nsTArray<int> receivedIDs;

Please add a comment as to how this is used, and a more descriptive variable name.
Attachment #8649166 - Flags: review?(gkeeley) → feedback+
Update the patch.
Attachment #8649166 - Attachment is obsolete: true
> Hi Bhavna,
> There are two reasons that we don't include it in this patch.
> 1. We cannot handle GSM_DEFAULT encoding right now.
>    It would like extra effort to decode this format.
> 2. By checking ETS-SUPL-V1.0, Requestor ID and Client name should be a
> optional features in SUPL 1.0.
>    SUPL-1.0-con-279 – Requestor ID and Client Name [Includes optional
> features]
> So we decide to land current patch into our 2.2 codebase first.
> 

Hi Bhavna:

We are considering to include more support than current work, before a fixed plan/schedule would you help me learn more about:

1. Do you know if there is existing carrier request, for SUPL 2.0 certification support? 
2. Is GSM_DEFAULT decoding a common use per your understanding?
3. When considering UI design, it would be good if we can know some exact example of "Requestor ID", "notification message", ..., is it possible you can help get some for our reference?

Thanks!
Flags: needinfo?(wehuang) → needinfo?(sbhavna)
Group: qualcomm-confidential
Flags: needinfo?(sbhavna)
Do you know if there is existing carrier request, for SUPL 2.0 certification support?
>> This information must be come from PM , may be Ravi. The plan /schedule must also come from PM.

Regarding your other 2 questions, I'll check if our test team can help.
Group: qualcomm-confidential
I think i hit the Qualcomm confidential Group by mistake, removing it.
Wesley / Alphan,

On the email discussion going on you'll had mentioned
<< According to the test case SUPL-2.0-con-024, the device should display *or use*  the notification messages >>
Can you point me to the exact document link you'll are using for the spec ? I have been referring to 
http://member.openmobilealliance.org/ftp/Public_documents/LOC/Permanent_documents/OMA-TS-ULP-V2_0_2-20140708-A.zip but I cannot really find the mention of this requirement.
Re-paste the question here.
   According to the test case SUPL-2.0-con-024, the device should display *or use*  the notification messages. Does it mean the device can also choose to print notification messages to ADB or save it to log file without violating the Pass-Criteria ?


The following is what we point out.
@ OMA-ETS-SUPL-V2_0_2-20140109-C.pdf

5.1.2.5 SUPL-2.0-con-024 – Requestor ID and Client Name
[Test Procedure]
  4. The SET displays or uses the Requestor ID and the Client Name set in step 2
[Pass-Criteria]
  5. At step 4 the SET shall correctly display or use: Requestor ID set in step 2. Client Name set in step 2
Hi Alphan,

Can you ask your question directly on the email thread going on with QC ?
It will be helpful for any other more questions that our PM may have to understand the issue.

What does Client Name map to in the GpsNiNotification structure ? I see a requestor_id and text, but not client name.
I think client name should be hidden in notification (text[]).

https://github.com/android/platform_hardware_libhardware/blob/master/include/hardware/gps.h#L897
/**
 * Requestor ID
 */
char            requestor_id[GPS_NI_SHORT_STRING_MAXLEN];

/**
 * Notification message. It can also be used to store client_id in some cases
 */
char            text[GPS_NI_LONG_STRING_MAXLEN];
Try server result on 2.2R.
https://treeherder.mozilla.org/#/jobs?repo=try&revision=4520596a76bc
It looks fine.
Hi Wesley,
we need to phase in this patch to 2.2r.
Please help on it.
Thanks.
Flags: needinfo?(whuang)
Keywords: checkin-needed
feature-b2g: --- → 2.2r+
Flags: needinfo?(whuang)
Alphan,

As discussed on the QC email thread, notification message display is a must. Will that be handled as a separate bug?
Yes, I will fill another bug for notification message display.
(In reply to Bhavna Sharma from comment #55)
> Alphan,
> 
> As discussed on the QC email thread, notification message display is a must.
> Will that be handled as a separate bug?

Bug 1201778 is for this request.
Blocks: 1201778
No longer blocks: 1195602
Blocks: 1195602
Comment on attachment 8649735 [details] [diff] [review]
[v2.2r-GECKO part] Bug 853703- support SUPL NI. r=jaliu

This patch is for 2.2r now.
Rename the patch.
Attachment #8649735 - Attachment description: [v2.2-GECKO part] Bug 853703- support SUPL NI. r=jaliu → [v2.2r-GECKO part] Bug 853703- support SUPL NI. r=jaliu
Comment on attachment 8639195 [details] [diff] [review]
[v2.2-GAIA part] Bug 853703- support SUPL NI

Remove this Gaia patch since we've moved it to bug 1195602 for easily tracking review process.
Attachment #8639195 - Attachment is obsolete: true
Whiteboard: [CR 927436]
Whiteboard: [CR 927436] → [caf priority: p2][CR 927436]
Firefox OS is not being worked on
Status: NEW → RESOLVED
Closed: 6 years ago
Resolution: --- → WONTFIX
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: