+++ 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?
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?
This provider is very specific to Google Location Service. if you are using another provider, you want another provider service.
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?
> 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
You can use Geolocater add-on.
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?
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. :)
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