886138 - Geolocation doesn't recognize JSON file to set fixed location

Status: RESOLVED FIXED

(Core :: DOM: Geolocation, defect)

Description

[Markus Popp]

In 2013-06-23 Nightly, Geolocation no longer recognizes a JSON file to set a fixed location.

To reproduce:

* install fresh instance with Linux64 Nightly of June 23rd, 2013
* create a file location.json with the following content:
{
    "status": "OK",
    "accuracy": 10.0,
    "location": {
        "lat": 40.689722222,
        "lng": -74.045
    },
    "access_token": "xF9F3la0"
}
* place location.json into the profile directory
* got to about:config and set geo.wifi.uri to:
file:///home/[user]/.mozilla/firefox/[profiledir]/location.json
(replace [user] and [profiledir] accordingly of course
* go to http://maps.google.com/
* click the Geolocation icon above zoom element and pegman
* see error message: Your location could not be determined

The same procedure worked with 2013-06-22 Nightlies and the occurrence of the bug coincides with the landing of GStreamer being enabled, as per bug 794282. Perhaps a clue that this may be related.

Comment 1

[Alice0775 White]

Regression window(m-i)
Good:
http://hg.mozilla.org/integration/mozilla-inbound/rev/3aa6deebc1be
Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20130621 Firefox/24.0 ID:20130621161502
Bad:
http://hg.mozilla.org/integration/mozilla-inbound/rev/7c0453f3ed70
Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20130621 Firefox/24.0 ID:20130621163503
Pushlog:
http://hg.mozilla.org/integration/mozilla-inbound/pushloghtml?fromchange=3aa6deebc1be&tochange=7c0453f3ed70

Regressed by:
6c236b24064b	Doug Turner — Bug 882485 - Add API keys support for Google Location Service API. r=gps, jdm, gavin. sr=brendan

Comment 2

[Doug Turner (:dougt)]

So, the only change that I think this might be is that we now have a test for the http status code.  Since you're running this over file:///, i bet it wont work anymore.

In NetworkGeolocationProvider.js:


   xhr.onload = function() {
        LOG("gls returned status: " + xhr.status + " --> " +  JSON.stringify(xhr.response));
        if (xhr.status != 200) {
            return;
	}


If you remove that if check, does it work?

Comment 3

[Markus Popp]

I placed location.json inside my local web server and referenced geo.wifi.uri to its http:// URI. That made it work again.

This strongly suggests your assumption is right.

Comment 4

[Doug Turner (:dougt)]

cool.  do you want to patch it, or should I?  If it is http, we should check for 200, otherwise just ignore the status.

Comment 5

[Markus Popp]

(In reply to Doug Turner (:dougt) from comment #4)
> cool.  do you want to patch it, or should I?  If it is http, we should check
> for 200, otherwise just ignore the status.

I'm not a Firefox developer, so probably better if you do ;).

Comment 6

[Josh Matthews [:jdm]]

We can create a URI object (like http://mxr.mozilla.org/mozilla-central/source/netwerk/test/unit/test_auth_jar.js#7) and check its scheme in http://mxr.mozilla.org/mozilla-central/source/dom/system/NetworkGeolocationProvider.js.

Comment 7

[:Gavin Sharp [email: [e-mail]]]

Probably better to check  xhr.channel instanceof Ci.nsIHttpChannel

Comment 8

[bhavana bajaj [:bajaj]]

:dougt, passing this on to you, please reassign if needed.Thanks !

Comment 9

[bhavana bajaj [:bajaj]]

needinfo on :dougt here : Doug, Is this still Fx24: affected given geolocation is disabled on 24 now ?

Comment 10

[Doug Turner (:dougt)]

> Is this still Fx24: affected

Yes

> given geolocation is disabled on 24 now ?

What does that mean?  Why would geolocation be disabled in 24?

Comment 11

[bhavana bajaj [:bajaj]]

(In reply to Doug Turner (:dougt) from comment #10)
> > Is this still Fx24: affected
> 
> Yes
> 
> > given geolocation is disabled on 24 now ?
> 
> What does that mean?  Why would geolocation be disabled in 24?

Whoops, sry I mixed this up with disabling the new wifi and cell tower tracking project which was disabled in Fx24(Bug 902783) and understand this is different to the Web API for Geolocation. My bad :(

Can you help with the next steps here ? Is this something that is going to be addressed in the next few days or you recommend untracking if the user impact is not serious enough to block on this ?

 We tracked this for Fx24 as this is a regression from Bug 882485.

Comment 12

[Doug Turner (:dougt)]

untrack it.  no user impact.

Comment 13

[mjh563]

Attachment: patch

Comment 14

[Ryan VanderMeulen [:RyanVM]]

https://hg.mozilla.org/integration/fx-team/rev/49e797ce0f22

Comment 15

[Ed Morley [:emorley]]

https://hg.mozilla.org/mozilla-central/rev/49e797ce0f22

Comment 16

[Oto]

*If in about:config geo.wifi.uri is set to:
data:application/json,{"location":{"latitude":42.65402,"longitude":21.1598,"accuracy":10}}

this also doesn't work anymore. Is it possible to fake/simulate http status code to 200 as workaround by using this approach?

Comment 17

[mjh563]

(In reply to Oto from comment #16)
> *If in about:config geo.wifi.uri is set to:
> data:application/json,{"location":{"latitude":42.65402,"longitude":21.1598,
> "accuracy":10}}
> 
> this also doesn't work anymore. Is it possible to fake/simulate http status
> code to 200 as workaround by using this approach?

You need to use "lat" and "lng", not "latitude" and "longitude":

data:application/json,{"location":{"lat":42.65402,"lng":21.1598,"accuracy":10}}

Comment 18

[mjh563]

Also, setting your own value in geo.wifi.uri will only work on systems where the default network geolocation provider is in use.

On systems that use their own provider (such as Mac since bug 874587 and then bug 928217), changing that pref will have no effect.

There should probably be a bug filed about that, if there isn't one already.

Comment 19

[Oto]

"Lat" and "lng" also doesn't work because it doesn't get HTTP OK status(200) response. Is it possible to simulate this response?

Comment 20

[Josh Matthews [:jdm]]

You can run a simple HTTP server in the same directory as the json file, and use localhost for the uri: python -m SimpleHTTPServer