Support UMTS/WCDMA cell networks in network location provider

RESOLVED FIXED in Firefox 32

Status

()

defect
RESOLVED FIXED
5 years ago
5 years ago

People

(Reporter: hschlichting, Assigned: garvan)

Tracking

unspecified
mozilla33
ARM
Gonk (Firefox OS)
Points:
---
Dependency tree / graph

Firefox Tracking Flags

(blocking-b2g:1.4+, firefox31 wontfix, firefox32 fixed, firefox33 fixed, b2g-v1.3T wontfix, b2g-v1.4 fixed, b2g-v2.0 fixed, b2g-v2.1 fixed)

Details

Attachments

(1 attachment)

The current code in NetworkGeolocationProvider.js hardcodes a radio type of "gsm" (http://mxr.mozilla.org/mozilla-central/source/dom/system/NetworkGeolocationProvider.js#211).

This needs to map the network type nsIMobileConnectionInfo.type to either gsm or wcdma, depending on what network is currently active.

'gsm', 'gprs' and 'edge' should be mapped to 'gsm'
'umts', 'hsdpa', 'hsupa', 'hspa' and 'hspa+' should be mapped to 'wcdma'

This might be slightly higher priority, as non-Tarako devices like the Flame will probably be frequently used on UMTS networks and currently neither GLS nor MLS can return any cell-based matches for these devices.
The line in question is now http://mxr.mozilla.org/mozilla-central/source/dom/system/NetworkGeolocationProvider.js#249 near the TODO type/radio comment.
In email, Hanno added that:

Currently the MLS query is hardcoded to radioType “gsm”. Which works fine on Tarako, as those devices only support 2.5G (gsm/edge). But Dolphin supports 3G/UMTS as well.

As of today, any Dolphin (or Flame) devices connected to a 3G / UMTS network won’t get a cell-based MLS position estimate. It will only work if the device is on a 2.5G network.
Blocks: mls-dolphin
blocking-b2g: --- → 1.4?
Added check for gsm or wcdma
Attachment #8443064 - Flags: review?(dougt)
Comment on attachment 8443064 [details] [diff] [review]
bug-1010278.patch

Looks good to me, service side f+ :)
Attachment #8443064 - Flags: feedback+
blocking-b2g: 1.4? → 1.4+
Attachment #8443064 - Flags: review?(dougt) → review+
Garvan: do we need to uplift this fix to B2G 1.4 or 2.0?
Assignee: nobody → gkeeley
Status: NEW → ASSIGNED
status-b2g-v1.4: --- → ?
status-b2g-v2.0: --- → ?
status-b2g-v2.1: --- → ?
Flags: needinfo?(gkeeley)
Doug's meta-patch included this fix for 1.4. There has been no discussions with me about what goes into the 2.0 branch, discussions were all 1.3t, then 1.4 more recently.
Flags: needinfo?(gkeeley)
Doug: Garvan says you are going to land this fix on 1.4 (and thus also central and Aurora 32 for 2.0).
Given that our typical branch landing policy mandates that 1) fixes land on trunk/master first, and 2) land on all affected branches, can we please get a disposition for v2.0/v2.1 here? If if it's wontfix, we shouldn't leave this sitting.
Flags: needinfo?(gkeeley)
I added checkin-needed, I see this only landed on 1.4.

Ryan, this patch is needed for all platforms indicated in the tracking flags.
Flags: needinfo?(gkeeley)
Keywords: checkin-needed
One more wrinkle - as of late last week, 1.4+ blockers no longer have automatic approval for landing on v2.0. Please request approval-mozilla-aurora on the patch for v2.0 uplift. I'll at least land it on b2g-inbound for the time-being.
(In reply to Ryan VanderMeulen [:RyanVM UTC-4] from comment #11)
> One more wrinkle - as of late last week, 1.4+ blockers no longer have
> automatic approval for landing on v2.0. Please request
> approval-mozilla-aurora on the patch for v2.0 uplift. I'll at least land it
> on b2g-inbound for the time-being.

Since we did not change the policy yet and I spoke chris/Garvan about the risk here, lets get this uplifted to 2.0
checkin-needed for b2g-v2.0 (Aurora 32). Fixed in 1.4 (comment 8) and 2.1 (comment 11).
https://hg.mozilla.org/mozilla-central/rev/5993d1e919b1
Status: ASSIGNED → RESOLVED
Closed: 5 years ago
Keywords: checkin-needed
Resolution: --- → FIXED
Target Milestone: --- → mozilla33
Blocks: 1031567
You need to log in before you can comment on or make changes to this bug.