596481 - Geolocation sometimes hangs without returning result or running any callbacks.

Status: VERIFIED FIXED

(Core :: DOM: Geolocation, defect)

Description

[[e-mail]]

User-Agent:       Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2.9) Gecko/20100824 Firefox/3.6.9
Build Identifier: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2.9) Gecko/20100824 Firefox/3.6.9

I am working on a website that uses geolocation. I noticed that it doesn't always work. It hangs for a long time, or if I have a timeout, it runs the error callback.

It seems to happen more often if I reload the page many times in a short period of time, like I sometimes do when I test my site. If I restart Firefox, then it works fine for a while, but eventually it stops working. It doesn't just happen on my site. I can see the same thing happen on this test page or any other site that uses this feature.

If I try the same sites in different browsers, it works fine. In Chrome, it works right away. In Safari, it may take some time, but it usually works.

I wish I could come up with a better test case but it seems to happen somewhat randomly, without any clear hint as to why it happens.

Reproducible: Sometimes

Steps to Reproduce:
1. Go to a webpage that uses geolocation ability.
2. Wait for it to come up with your location, or some sort of result, or some sort of hint as to whether it will eventually come up with a result, or if anything went wrong.
Actual Results:  
If there is a value set for maximumAge, the error callback will run. If not, it will keep me waiting seemingly forever.

Expected Results:  
The browser should figure out my location.

I tried this both on Mac OS X and Windows XP. I noticed this issue in Firefox 3.6.6 and I still notice it in Firefox 3.6.9.

Comment 1

[Josh Matthews [:jdm]]

I'm not seeing any problem in the latest FF4 nightly.  How about you?

Comment 2

[dennispopel]

Experiencing the same issue on Mozilla/5.0 (Windows; U; Windows NT 6.0; en-GB; rv:1.9.2.8) Gecko/20100722 Firefox/3.6.8 (.NET CLR 3.5.30729)

Seems to be happening when free RAM is low (because of Firefox taking up to 300MB of RAM, which, for some reason, is "normal" for it, even after closing all tabs).

However, yesterday it happened to me after "cold reboot" - ie, powering my laptop down and starting it up and then starting firefox.

Comment 3

[[e-mail]]

I recently learned about the geo.wifi.logging.enabled preference in about:config. It lets me see what is being sent and received by geolocation function calls, which may give some clue as to what is happening. It seems like some data is being sent regarding wi-fi access points and some data is being received with my coordinates and address, but the success callback is not being called for some reason.

I noticed that on both the benwerd.com page in this bug report, and in my own tests. This is in Firefox 3.6.12.

Comment 4

[[e-mail]]

I did some more experimenting and noticed that I sometimes experience this problem even in safe mode, with all my extensions disabled.

Comment 5

[Tom Wuttke]

This happens to me also.  I can reproduce it using twitter.com and a macbook. I dug through the source code and have a potential fix.

The issue is: If the location service (one per browser session) caches an accurate position, it will reject any future positions that are less accurate, and never dispatch callbacks to any new location listeners.  I am preparing a patch to fix this, as well as another issue where callbacks sometimes keep coming even after a location watch has been cleared.

Comment 6

[Tom Wuttke]

Attachment: Proposed fix

Comment 7

[Doug Turner (:dougt)]

thanks for the patch.  i will try to review this week.

Comment 8

[Alon Zakai (:azakai)]

Comment on attachment 494924 [details] [diff] [review]
Proposed fix

Patch looks good to me.

Comment 9

[Tom Wuttke]

Thanks Doug.  Looking forward to it. 

I noticed other potential issues in this code, but they don't break the base
functionality for me as much as the case addressed above. Maybe they could be
new bugs if they seem interesting to anyone. 

For example, when a watch position is created, if the cached positon is already
acceptable, the code looks like it might terminate the watch (request).  This
will prevent future notifications if the user moves significantly (like on a
train), unless the request is cleared and restarted periodically (polling)
which kind of defeats the point of the watch instead of the get in the first
place.

  nsGeolocation::WatchPosition
calls 
  request->Allow()
which runs this if the cached result is acceptable:
    nsCOMPtr<nsIRunnable> ev = new RequestSendLocationEvent(lastPosition, this,
mLocator);
    NS_DispatchToMainThread(ev);
which calls
  RequestSendLocationEvent::Run
which does this
    if (mLocator)
      mLocator->RemoveRequest(mRequest);
which seems to me like it will mute the watch request from receiving future
updates.

The other thing I was wondering about but didn't spend time investigating was:
What is the frequency of update callbacks from a watch?  If the frequency is
low, then my fix would not solve the case where another tab already has a geo
watch session running, because the new positions would not get dispatched
timely enough for the new tab to get its first position before its expiry
timeout. I'm not sure of the best way to fix that case, other than maybe to
kick the service into rebroadcasting its last known location.

A side comment about the geo watch:
Chrome is interesting in that when you do a geo watch, they return a rough
location fix (presumably based on your ip address) very quickly, and a few
seconds later return a more precise result based on public wifis nearby. I had
to write some weird special case code on our web site to wait a few extra
seconds in case the position became more accurate, otherwise use the rough
location. Firefox doesn't currently act this way as far as I could tell.

Comment 10

[Wikiwide]

Bug 495294 isn't fixed.
In Fennec nightly, 2010-12-07, Maemo 5, Qt.
When watch is cleared, GPS (locked or not) is disconnected (very good), and then later errorCallback (timeout) is invoked.

Comment 11

[Wikiwide]

(In reply to comment #10)

Waiting for this patch to land.
Thanks to everybody.

Comment 12

[Josh Matthews [:jdm]]

This isn't ready for checkin, as it needs approval.

Comment 13

[Doug Turner (:dougt)]

Tom, would it be hard to write a test for this change?

Comment 14

[Tom Wuttke]

Attachment: Now with a unit test

Comment 15

[Tom Wuttke]

Doug, do I need to do anything else to get this approved and committed?  I don't really want to go through the whole process of being able to submit patches, this is just a one-off fix for me because this bug was messing up my web site and there is no possible workaround other than to fix Firefox.

Comment 16

[Doug Turner (:dougt)]

Hey Tom.  Was on vacation.  Will look at this patch shortly.

Comment 17

[Doug Turner (:dougt)]

pushed to try.

Comment 18

[Doug Turner (:dougt)]

Comment on attachment 497716 [details] [diff] [review]
Now with a unit test

i'll push shortly.

Comment 19

[Doug Turner (:dougt)]

tom, thanks for the fix and the test!  It was super helpful.  Regards.

http://hg.mozilla.org/mozilla-central/rev/be9ca19e4f0f