1010278 - Support UMTS/WCDMA cell networks in network location provider

Status: RESOLVED FIXED

(Core :: DOM: Geolocation, defect)

Description

[Hanno Schlichting]

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.

Comment 1

[Hanno Schlichting]

The line in question is now http://mxr.mozilla.org/mozilla-central/source/dom/system/NetworkGeolocationProvider.js#249 near the TODO type/radio comment.

Comment 2

[Chris Peterson [:cpeterson]]

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.

Comment 3

[:garvan]

Attachment: bug-1010278.patch

Added check for gsm or wcdma

Comment 4

[Hanno Schlichting]

Comment on attachment 8443064 [details] [diff] [review]
bug-1010278.patch

Looks good to me, service side f+ :)

Comment 5

[Chris Peterson [:cpeterson]]

Garvan: do we need to uplift this fix to B2G 1.4 or 2.0?

Comment 6

[:garvan]

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.

Comment 7

[Chris Peterson [:cpeterson]]

Doug: Garvan says you are going to land this fix on 1.4 (and thus also central and Aurora 32 for 2.0).

Comment 8

[Doug Turner (:dougt)]

https://hg.mozilla.org/releases/mozilla-b2g30_v1_4/rev/dea30f28e08e

Comment 9

[Ryan VanderMeulen [:RyanVM]]

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.

Comment 10

[:garvan]

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.

Comment 11

[Ryan VanderMeulen [:RyanVM]]

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.

Comment 12

[Ryan VanderMeulen [:RyanVM]]

https://hg.mozilla.org/integration/b2g-inbound/rev/5993d1e919b1

Comment 13

[bhavana bajaj [:bajaj]]

(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

Comment 14

[Chris Peterson [:cpeterson]]

checkin-needed for b2g-v2.0 (Aurora 32). Fixed in 1.4 (comment 8) and 2.1 (comment 11).

Comment 15

[Carsten Book [:Tomcat]]

https://hg.mozilla.org/mozilla-central/rev/5993d1e919b1

Comment 16

[Ryan VanderMeulen [:RyanVM]]

https://hg.mozilla.org/releases/mozilla-aurora/rev/e2b455dd98dc