Network location provider unconditionally appends extra data to the provider URL

RESOLVED WORKSFORME

Status

()

Core
Geolocation
RESOLVED WORKSFORME
5 years ago
4 years ago

People

(Reporter: jdm, Unassigned)

Tracking

Firefox Tracking Flags

(Not tracked)

Details

(Reporter)

Description

5 years ago
+++ This bug was initially created as a clone of Bug #677256 +++

Comment 13 - Ka-Hing Cheung - 2011-11-17 22:02:13 PST

The new scheme unconditionally appends "?browser=firefox&sensor=true" to the end of geo.wifi.uri, which breaks manually setting that pref to a data uri to force a particular location. In my case I don't have wifi on this computer so I want to override the IP based detection with something more accurate. Is there a workaround?
(Reporter)

Comment 1

5 years ago
This could be a reasonable concern. Doug, should we only be appending those extra values if we're using the default provider, or should we document that any provider used must not break in the presence of those values?

Comment 2

5 years ago
This provider is very specific to Google Location Service.  if you are using another provider, you want another provider service.

Comment 3

5 years ago
The geo.wifi.uri used to be a way to specify a static location for automated testing.  I could set geo.wifi.uri to a "data:" uri with a valid service result, allowing me to depend on a specific location in my Selenium tests.  Does this mean that it's now impossible to write tests of this sort with Firefox, or is there some other way to override the location now?

Comment 4

5 years ago
>  could set geo.wifi.uri to a "data:" uri with a valid service result, allowing me to depend on a specific location in my Selenium tests.

Right, that will no longer easily work since we are passing a query.

>  Does this mean that it's now impossible to write tests of this sort with Firefox

No, we have tests in the tree that test it right now:
  http://mxr.mozilla.org/mozilla-central/source/dom/tests/mochitest/geolocation/network_geolocation.sjs

Something like this will work too:
  https://github.com/dougt/geofake-server

> is there some other way to override the location now?

yup.  See above. ;D

Comment 5

5 years ago
You can use Geolocater add-on.

Comment 6

5 years ago
It seems this bug is really about the inability to manually specify location rather than how the location provider URI is formed.  The manipulations of geo.wifi.uri could be done in a way that allows for manually provided location data to be pulled from data: and/or file:.  However, manually provided location data could also be pulled from a hidden geo.locationOverride preference via JSON.parse or what have you.

As it stands now, users must either share potentially very precise location data with a third party location provider (a very significant privacy issue that leads many to disable geo location), install a third party addon (a potential security and/or privacy issue), or setup their own web server to handle location queries (a challenge from the typical user point of view).  Simply adding a pref string would be far easier and user friendly.  What are we talking about here... a few to a dozen lines of code to support this?  Is there objection to this?

Comment 7

5 years ago
Hi Jessie,  No one is objecting to fixing this.  It just happens to be a very low priority.  Patches happily accepted.  I'll or jdm will review promptly.  :)

Comment 8

4 years ago
I don't think this bug is still valid, is it? Nothing currently gets appended to the geo.wifi.uri URI. 

Custom URIs (including data: URIs) should work as expected on platforms that use the network provider, provided the response is in the correct format, ie. the response format from the Google Geolocation API that's described here:

https://developers.google.com/maps/documentation/business/geolocation/#responses
(Reporter)

Comment 9

4 years ago
Agreed.
Status: NEW → RESOLVED
Last Resolved: 4 years ago
Resolution: --- → WORKSFORME
You need to log in before you can comment on or make changes to this bug.