Closed Bug 886138 Opened 7 years ago Closed 7 years ago

Geolocation doesn't recognize JSON file to set fixed location

Categories

(Core :: DOM: Geolocation, defect)

x86_64
All
defect
Not set

Tracking

()

RESOLVED FIXED
mozilla27
Tracking Status
firefox24 - affected

People

(Reporter: markus.popp, Assigned: mjh563)

References

Details

(Keywords: regression, Whiteboard: [mentor=jdm][lang=js])

Attachments

(1 file)

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.
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
Blocks: 882485
Keywords: regression
OS: Linux → All
Component: General → Geolocation
Product: Firefox → Core
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?
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.
cool.  do you want to patch it, or should I?  If it is http, we should check for 200, otherwise just ignore the status.
(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 ;).
Probably better to check  xhr.channel instanceof Ci.nsIHttpChannel
Assignee: nobody → doug.turner
:dougt, passing this on to you, please reassign if needed.Thanks !
needinfo on :dougt here : Doug, Is this still Fx24: affected given geolocation is disabled on 24 now ?
Flags: needinfo?(doug.turner)
> Is this still Fx24: affected

Yes

> given geolocation is disabled on 24 now ?

What does that mean?  Why would geolocation be disabled in 24?
Flags: needinfo?(doug.turner)
(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.
untrack it.  no user impact.
Attached patch patchSplinter Review
Assignee: doug.turner → mjh563
Status: NEW → ASSIGNED
Attachment #812775 - Flags: review?(josh)
Attachment #812775 - Flags: review?(josh) → review+
Keywords: checkin-needed
https://hg.mozilla.org/integration/fx-team/rev/49e797ce0f22
Keywords: checkin-needed
Whiteboard: [mentor=jdm][lang=js] → [mentor=jdm][lang=js][fixed-in-fx-team]
https://hg.mozilla.org/mozilla-central/rev/49e797ce0f22
Status: ASSIGNED → RESOLVED
Closed: 7 years ago
Resolution: --- → FIXED
Whiteboard: [mentor=jdm][lang=js][fixed-in-fx-team] → [mentor=jdm][lang=js]
Target Milestone: --- → mozilla27
*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?
(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}}
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.
"Lat" and "lng" also doesn't work because it doesn't get HTTP OK status(200) response. Is it possible to simulate this response?
You can run a simple HTTP server in the same directory as the json file, and use localhost for the uri: python -m SimpleHTTPServer
You need to log in before you can comment on or make changes to this bug.