492633 - Sometimes accuracy of geolocation differs drastically

Status: RESOLVED WORKSFORME

(Core :: DOM: Geolocation, defect)

Description

[Henrik Skupin [:whimboo][⌚️UTC+1]]

Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.1b5pre) Gecko/20090512 Shiretoko/3.5b5pre ID:20090512031310

Running the above build and opening the following URL shows a location which is about 4km far away from my current position. Using Minefield instead I get an accuracy of about ~40m difference to my position.

http://people.mozilla.org/~dougt/geo.html

So are there some changes which haven't been checked into 1.9.1 yet or is this a branch only bug?

Users cannot trust the given location they get and will probably not find the excellent restaurant in a foreign city. Is it worth asking for blocking1.9.1?

Comment 1

[(mostly gone) XtC4UaLL [:xtc4uall]]

for me
Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2a1pre) Gecko/20090512 Minefield/3.6a1pre ID:20090512044242
and
Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.1b5pre) Gecko/20090512 Shiretoko/3.5b5pre ID:20090512041901
give the same output.

Comment 2

[Doug Turner (:dougt)]

Hi,

Maybe you can help me further debug this.  In your installation, there is a file called NetworkGeolocationProvider.js.  In NetworkGeolocationProvider.js there is a function called LOG:

http://mxr.mozilla.org/mozilla-central/source/dom/src/geolocation/NetworkGeolocationProvider.js#12

Could you uncomment both lines, try again, and send me the javascript console?  You may not want to post it here because it will contain your location as given by the location provider. 

If you don't know what I am taking about, please ignore.

Comment 3

[Henrik Skupin [:whimboo][⌚️UTC+1]]

So as what I can see the first value we get back from the geolocation provider has this high accuracy value only. Positions returned later have the correct value. Looking at the log the initial position is based on only two wifi networks. Could this be the problem? Now I'm in another network and everything seems to be fine. Even the initial position is shown correctly.

Comment 4

[Doug Turner (:dougt)]

whimboo sent me the network log.  in the case where accuracy is high, there is an extra access point visible.  in the case where accuracy is low, it is missing that access point.  I am not sure the difference between shiretoko and mindfield.  Instead, i think it has to do with this missing access point.

Comment 5

[Henrik Skupin [:whimboo][⌚️UTC+1]]

Doug, its the other way around. The high accuracy is returned for the 2 nodes while 3 nodes result in a lower accuracy value but better position.

Comment 6

[Doug Turner (:dougt)]

yeah, the wording is messy

good accuracy == high accuracy == low accuracy value (measured in meters)
bad accuracy == low accuracy == high accuracy value (measured in meters)

Comment 7

[Henrik Skupin [:whimboo][⌚️UTC+1]]

Doug, have you been checked in any patches lately? While trying to identify the cause with the older profile I cannot see it anymore. Even the first return position is fine now.

Ok, probably it's really dependent on the amount of wifi networks. Right now 3 of them are in my log while only 2 were listed when I noticed this problem.

Comment 8

[Henrik Skupin [:whimboo][⌚️UTC+1]]

Some minutes ago I got a totally strange result. When opening the referenced URL inside the Private Browsing mode for a fresh profile I got the position of my previous home. I moved nearly two month ago. So what happens here? The accuracy value was 150 so it's not bad.

Comment 9

[Doug Turner (:dougt)]

i haven't checked in anything related to the wifi scanning stuff and there shouldn't be much difference between trunk and 1.9.1.


basically the way this works is that Google (and other similar services) drive around listening for WiFi radios.  From the street you can hear most WiFi radios.  in the vehicle there is also a GPS.  So, they can match up what WiFi radio they hear at some given GPS location.

What I think you might be seeing is they drove by your old place, then you moved, and they haven't rescanned.

If you want, i can forward them the information so that they can try to correct this.  In the future, i would hope that there will be a "self service" site such that I am not the bottle neck (i just can't do this for everyone).

Comment 10

[Henrik Skupin [:whimboo][⌚️UTC+1]]

Doug, this only happens when I start the geolocation service from within the Private Browsing mode right after the profile has been created. The initial value shows this strange location. The second one has the correct location but with an accuracy of ~12000.

I don't think that this is caused by some old measured values. Therefor we have too many different code paths when a wrong position is reported back.

Comment 11

[Doug Turner (:dougt)]

Henrik, can you uncomment the code in LOG() and send me the traffic?  I am wondering what we are sending differently between these two requests.

Comment 12

[Henrik Skupin [:whimboo][⌚️UTC+1]]

I sent a log to Doug.

Comment 13

[Mike Beltzner [:beltzner, not reading bugmail]]

I can't reproduce this. Every combination of private browsing, minefield, shiretoko, etc returns the same location result for me. Which, btw, has a high accuracy range because Google hates them some Canada or something.

Not blocking until we get solid STR.

Comment 14

[Henrik Skupin [:whimboo][⌚️UTC+1]]

This happens when you only have 2 access points around you. Even with such an amount it shouldnt return a position which is 3km far away. Wifi doesn't work over such distances.

Comment 15

[Doug Turner (:dougt)]

Henrik, are you getting better locations now?

Comment 16

[Henrik Skupin [:whimboo][⌚️UTC+1]]

Still not better even with more then 2 access points.

Comment 17

[Henrik Skupin [:whimboo][⌚️UTC+1]]

Doug, any progress on this bug? Right now I have normally more then 3 access points in my list. I saw it again while running the BFT against geo location. The first two tabs had the correct position while successive ones had the wrong position. Even after reloading the tabs nothing changes.

Comment 18

[Marcia Knous [:marcia]]

While running the RC candidate, I am seeing the following:

1. Run doug's test case on my Intel Mac with a wifi connection.
2. Service reports the address as 800 High School Way
Mountain View, CA 94041

The zip is right but the location seems to be a bit off - is that expected? Earlier I saw an instance in the lab with ethernet where they had me in the middle of Moffett field.

Comment 19

[Doug Turner (:dougt)]

This is the text from our FAQ

"""
Accuracy varies greatly from location to location. In some places, our service providers may be able to provide a location to within a few meters. However, in other areas it might be much more than that. All locations returned by our service providers are estimates only and we do not guarantee the accuracy of the locations provided. Please do not use this information for emergencies. Always use common sense.
"""


I am marking as wfm