Closed Bug 596481 Opened 13 years ago Closed 13 years ago
Geolocation sometimes hangs without returning result or running any callbacks
User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:188.8.131.52) Gecko/20100824 Firefox/3.6.9 Build Identifier: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:184.108.40.206) 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.
Component: General → Geolocation
Product: Firefox → Core
QA Contact: general → geolocation
I'm not seeing any problem in the latest FF4 nightly. How about you?
Experiencing the same issue on Mozilla/5.0 (Windows; U; Windows NT 6.0; en-GB; rv:220.127.116.11) 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.
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.
I did some more experimenting and noticed that I sometimes experience this problem even in safe mode, with all my extensions disabled.
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.
thanks for the patch. i will try to review this week.
Status: UNCONFIRMED → NEW
Ever confirmed: true
Comment on attachment 494924 [details] [diff] [review] Proposed fix Patch looks good to me.
Attachment #494924 - Flags: review+
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.
Assignee: nobody → mozillatomwuttke
Version: unspecified → Trunk
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.
(In reply to comment #10) Waiting for this patch to land. Thanks to everybody.
This isn't ready for checkin, as it needs approval.
Tom, would it be hard to write a test for this change?
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.
Hey Tom. Was on vacation. Will look at this patch shortly.
pushed to try.
Comment on attachment 497716 [details] [diff] [review] Now with a unit test i'll push shortly.
Attachment #497716 - Flags: review?(doug.turner) → review+
tom, thanks for the fix and the test! It was super helpful. Regards. http://hg.mozilla.org/mozilla-central/rev/be9ca19e4f0f
Status: NEW → RESOLVED
Closed: 13 years ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.