Closed Bug 689252 Opened 10 years ago Closed 10 years ago

cleanup/remove geo.wifi.* preferences


(Core :: DOM: Geolocation, defect)

Not set





(Reporter: dougt, Assigned: dougt)



(Keywords: addon-compat)


(1 file)

No description provided.
Attached patch patch v.1Splinter Review
Attachment #562575 - Flags: review?(josh)
Attachment #562575 - Flags: review?(josh) → review+
Closed: 10 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla9
Comment on attachment 562575 [details] [diff] [review]
patch v.1

>+    let providerUrlBase = "";

Is it legally OK that every Mozilla-based app, including SeaMonkey and any XULRunner application that would hook up Geolocation, is now automatically using this provider? I thought Google explicitly only lets us use this for actual Firefox?
I'm surely OK with having it be used by everybody, but I'm worried that Google may not agree with me here.
Why is this hard-coded now?
Keywords: addon-compat
Why is this no longer configurable? There's not a single comment in this bug explaining the rationale.

This kills projects like Geomena dead.
A configurable geolocation provider is a critical freedom in locative web technology. Its as if Ubuntu decided to remove /etc/resolv.conf and hard code the DNS server IP address. Please restore this option. Both Firefox and Opera support this setting..

I started the project to create a creative commons licensed alternative to the  wifi location databases of google, apple, and skyhook. Having the geo.wifi.url setting makes this possible.
I would appreciate explanation too.
The preference is still honored, it is just not in about:config.
How is a firefox user meant to configure the geolocation provider, then?
Looking at the patch, we have this:

> -    let providerUrlBase = Services.prefs.getCharPref("geo.wifi.uri");
> +    let providerUrlBase = "";
> +    try {
> +        providerUrlBase = Services.prefs.getCharPref("geo.wifi.uri");      
> +    } catch (x) {};

So, the default value is no longer in the preferences, but the code still tries to see if there's anything set there and uses that value instead, if set.

In about:config it should still be possible to create a string preference with that name, and it should work correctly.
Thanks for pointing that out.
yup.  we currently do this for testing.
I should have take a look in the patch.
(In reply to Sonny Piers from comment #13)
> I should have take a look in the patch.
> Thanks.

No worries. This confusion happens more easily when bugs don't have any comments or explanation. It got me too :)
Blocks: 710784
You need to log in before you can comment on or make changes to this bug.