New issue
Advanced search Search tips
Note: Color blocks (like or ) mean that a user may not be available. Tooltip shows the reason.

Issue 152428 link

Starred by 5 users

Issue metadata

Status: Fixed
Email to this user bounced
Closed: Sep 2012
EstimatedDays: ----
NextAction: ----
OS: All
Pri: 1
Type: Bug

Sign in to add a comment

navigator.geolocation.getCurrentPosition does not work : callback not called

Reported by, Sep 26 2012

Issue description

Chrome Version       : 24.0.1275.0 canary
OS Version: 6.0 (Windows Vista, Windows Server 2008)
URLs (if applicable) :
Other browsers tested:
Add OK or FAIL after other browsers where you have tested this issue:

     Safari 5: Who ?
  Firefox 15 : OK
     IE 7/8/9: I don't think I want to launch this, sorry
Chrome 22.0.1229.79 : OK

What steps will reproduce the problem?
1. Open a page requesting geoloc acces with :
     navigator.geolocation.getCurrentPosition(function(position) {
        alert([position.coords.latitude, position.coords.longitude]);

For instance : 

2. If your Chrome settings say it should ask permission, the permission bar will be displayed

3. Grant permission, then nothing happens.

What is the expected result?
The callback should be called with the geoloc information

What happens instead?
The callback is not called.

Please provide any additional information below.
It does not work in extensions code as well.
It does not work even if the settings do not require explicit per site permission request.

UserAgentString: Mozilla/5.0 (Windows NT 6.0) AppleWebKit/537.12 (KHTML, like Gecko) Chrome/24.0.1275.0 Safari/537.12


Comment 1 by, Sep 26 2012

Labels: -Area-Undefined -OS-Windows Area-Internals OS-All Feature-Location Action-BisectNeeded Mstone-23 ReleaseBlock-Beta
Status: Untriaged
I can reproduce this in 23.0.1271.1 on 10.7 too.

Comment 2 by, Sep 26 2012

Labels: -Pri-2 Pri-1
Status: Assigned
pls look ASAP
mihai is that 10.7 mac os x? For me, it seems to be working fine on 23.0.1271.6 dev Mac os X 10.7.4. 

Status: Started
Also working here on mac laptop on Mac OS X canary 24.0.1278.0. 
Bisected between 23.0.1236.0 (working build) and 23.0.1270.0 (broken build) on Windows 7 64-bit

You are probably looking for a change made after 156268 (known good), but no later than 156278 (first known bad).
Labels: -Action-BisectNeeded

Comment 8 by, Sep 26 2012

Status: Fixed
ty so much 

we reverted the and CLs that caused this.
Committed revision 158817. and Committed revision 158819. for M23. 

John's gonna revert from trunk now. 

Comment 9 by, Sep 26 2012

FWIW, I can't reproduce this at work (also on Mac OS X 10.7), but it was definitely happening at home. Perhaps the Google Location Service API gives different responses to corp IPs?
Yes, I think that the geolocation API may not be accessible from outside of corp. I have contacted the GLS team to confirm. 

Holding off on trunk revert for now.
Confirmed that the issue was network accessibility of the GLS server. This has now been fixed, so I have not reverted the patches on trunk.

Karen, please could you revert the reverts in M23 branch?
Sorry if I missed something, but I'm still seeing it fail :(
Hi Xavier, does the computer you are running Chrome on have wifi?
No, but I could test that. Should I ?
It should then use the IP geoloc information, right ?
My other tests on same computer with Chrome 22 run fine, 
as well as with Firefox, but of course with a bad accuracy.
Thanks Xavier, I think that the problem is that with switch to the new geolocation API, the client's IP address is not being used when there is no wifi access point information. 

If you have easy access to a machine with wifi, can you confirm that it works for you?
No, it does not work either. I disconnected my ethernet cable to be 100% sure I was connected through wifi.
And it's still working on chrome 22 (but contrary to what I though with no better accuracy than when cable-connected, which is logical if only IP is used and not SSID)
I made another test checking for sent requests and I can't see any, so I wonder if there is some kind of cache that would make the browser still consider I'm not on wifi ? 
My test would then be invalid.
Let me know if there is such a thing and how it can be reset.

Anyway, if it worked in Wifi, it would still be a bug in case of non-wifi, right ?
You might need to restart chrome after ensuring that the wifi is working. 

Yes, I agree. We should fix the case of non-wifi geolocation.
Of course, I did restart it, several time, with no change.

To answer your question in #17, there's no client-side cache.

I think you're hypothesis in #16 is correct --  I'm guessing that the backend server doesn't have enough information to map your wireless access point list into a geolocation, so it's falling back to IP based location, which works on Chrome 22 which uses the old backend, but not on Chrome canary which uses the new backend.
I take back what I said in #17, there are requests to googleapis when I request geoloc, but they quickly disappear from the program I'm using to monitor for a reason I don't get.

If it's using google apis for geoloc, one might assume it would get the same accuracy than what Google Maps gets on Android ? Which is very good for me on the same SSID...
But that's a little off-topic...
huh hello ? How was this bug fixed ? when will the fix be available ?
I have Version 24.0.1286.0 canary and still see the issue.
The bug is fixed on M23, because that is using the old API. We're still working on fixing this in Canary.
oh ok cool, thanks
Xavier, this should be fixed on Canary - could you try it again please?

Just tested it on Version 24.0.1291.1 canary, and it's working fine !
Thanks a lot, and keep up the good work.
Thanks for the quick reply, much appreciated!
Project Member

Comment 28 by, Oct 18 2012

Labels: merge-merged-1271
The following revision refers to this bug:

r162699 | | 2012-10-18T13:54:24.553920Z

Changed paths:

Reapply geolocation network protocol changes.

This CL reapplys revisions:

Which is effectively a revert of revision 158817 and revision 158819.

The new geolocation backend has been fixed, and no changes were
required to the code in Chromium, so it desirable to have M23 using
the new geolocation protocol.

BUG= 152428 
Review URL:

Comment 29 by, Oct 18 2012

Labels: Merge-Merged

Comment 30 by Deleted ...@, Nov 20 2012


Comment 31 by Deleted ...@, Nov 20 2012


Project Member

Comment 32 by, Mar 10 2013

Labels: -Area-Internals -Feature-Location -Mstone-23 Cr-Content-Location Cr-Internals M-23
Project Member

Comment 33 by, Apr 5 2013

Labels: Cr-Blink
Project Member

Comment 34 by, Apr 6 2013

Labels: -Cr-Content-Location Cr-Blink-Location
Components: Blink>Geolocation
Components: -Blink>Location

Sign in to add a comment