Closed Bug 888252 Opened 7 years ago Closed 7 years ago
Geolocation position is not displayed on Nightly
I saw this while working on bug 758187, when using http://mozqa.com/data/firefox/geolocation/position.html (or the local repository page) on the latest nightly build, but not with the one from June 22nd for example. On Aurora or Release it works, tried with 2 OS X and 2 linux machines.
Please find the exact regression range.
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
WFM, windows + mac
Status: NEW → RESOLVED
Closed: 7 years ago
Resolution: --- → WORKSFORME
Nope, this is not fully fixed. At least not for Firefox 24.0. There might have been a fix in the last week which fixed that problem on Nightly. A build from July 8th is failing, but not the one from yesterday. When I test yesterdays Aurora build it is still not working. So there might be a patch which needs to be backported to Aurora to get this fixed. Could someone please check which changeset fixed that for Nightly?
Henrik, I think you're right. There are a couple parts. The first part is the client code changes required by Google to support their new API. This change landed on m-c and was uplifted to m-a as it followed the train. The second part was a releng's change about moving a api keys into the right place for the builders to use. I suspect that this change didn't make it to the m-a builders (I am not sure if I informed releng it should or not.) catlee, can you check to see if the api key is staged for the m-a builder?
Fixed window(m-i) Bad: http://hg.mozilla.org/integration/mozilla-inbound/rev/468b35185c44 Mozilla/5.0 (Windows NT 6.1; WOW64; rv:25.0) Gecko/20130710 Firefox/25.0 ID:20130710064558 Fixed: http://hg.mozilla.org/integration/mozilla-inbound/rev/b7d6458d2a3c Mozilla/5.0 (Windows NT 6.1; WOW64; rv:25.0) Gecko/20130710 Firefox/25.0 ID:20130710075527 Pushlog: http://hg.mozilla.org/integration/mozilla-inbound/pushloghtml?fromchange=468b35185c44&tochange=b7d6458d2a3c I guess fixed by: 4ee2783daa47 Chris AtLee — Bug 883233: Use API key for desktop builds. r=ted
Thanks Alice! That's the correct bug, yes.
Umm I got a different fixed range on linux i686 build... Fixed window(m-c) Bad: http://hg.mozilla.org/mozilla-central/rev/4dda210929fb Mozilla/5.0 (X11; Linux i686; rv:25.0) Gecko/20130712 Firefox/25.0 ID:20130712062937 Fixed: http://hg.mozilla.org/mozilla-central/rev/0b5b6c4b0e3a Mozilla/5.0 (X11; Linux i686; rv:25.0) Gecko/20130712 Firefox/25.0 ID:20130712101555 Pushlog: http://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=4dda210929fb&tochange=0b5b6c4b0e3a Fixed by: 0b5b6c4b0e3a Rail Aliiev — Bug 886842 - Add clang trunk builds for ASan. r=froydnj
Hm, that doesn't seem to be related. Have you accidentally picked a wrong changeset?
(In reply to Henrik Skupin (:whimboo) from comment #9) > Hm, that doesn't seem to be related. Have you accidentally picked a wrong > changeset? Now still, Tinderbox builds of comment#8 are available in bad: http://ftp.mozilla.org/pub/mozilla.org/firefox/tinderbox-builds/mozilla-central-linux/1373635777/ Fixed: http://ftp.mozilla.org/pub/mozilla.org/firefox/tinderbox-builds/mozilla-central-linux/1373649355/
(In reply to Doug Turner (:dougt) from comment #5) > Henrik, I think you're right. > > There are a couple parts. The first part is the client code changes > required by Google to support their new API. This change landed on m-c and > was uplifted to m-a as it followed the train. > > The second part was a releng's change about moving a api keys into the right > place for the builders to use. I suspect that this change didn't make it to > the m-a builders (I am not sure if I informed releng it should or not.) > > catlee, can you check to see if the api key is staged for the m-a builder? The file should be available on all builders. We would know for sure if you could land the patch that makes configure fail if the specified file doesn't exist ;)
So what's left to be done for 24.0 here? It's still not working in latest builds.
Status: REOPENED → ASSIGNED
My mistake here, when I checked today I didn't had the latest Aurora. It is working now, thanks!
Geolocation works fine on: FF 24b10 on Win 7, Mac OS X 10.8.4, Ubuntu 13.04 FF 25.0a2 (2013-09-12), 26.0a1 (2013-09-12) on Win 7, Ubuntu 13.04 So, it doesn't work on Mac OS X on latest aurora and nightly - "Unknown error acquiring position"
Still not working on FF 25b2 and up on Mac (works in FF 24). After opening http://mozqa.com/data/firefox/geolocation/position.html a warning shows up saying to enable the location services from Privacy preferences. But still doesn't work after checking the "enable location services" option in Privacy. http://img266.imageshack.us/img266/8462/gvxu.png
Lets get this checked again for 25.0 beta builds. Andreea, can you please have a look too? Is our test still not running?
Our automated test works fine on OS X with latest Nightly, Aurora and Beta. But when doing the manual steps, I see what Paul has mentioned. But in Mozmill we have set the 'geo.provider.testing' pref to true, to avoid that dialog that OS X has for sharing location.
Which version of OS X are you both using? It works fine for me with 25.0b1 on OS X 10.7.
I'm on 10.8.5
(In reply to Andreea Matei [:AndreeaMatei] from comment #19) > I'm on 10.8.5 So please test on 10.6 and 10.7 too. If it works on those versions of OS X, we most likely are seeing a different issue with OS X 10.8. In that case we have to get a new bug filed.
Still doesn't work to me on 10.6.8 and 10.7.5, FF 25b2, 27.0a1. But there is no problem in FF 24.
Is this an OS X-specific issue? The URL works for me on Linux nightly and 25 beta.
(In reply to mjh563 from comment #22) > Is this an OS X-specific issue? yes
Ok, so lets get a new bug filed if that only affects OS X but works on all the other platforms. Make sure it's getting tracked for Firefox 25.
Filed bug 923618 for the remaining issues. Marking this one verified.
Should this be fixed in Aurora now? Geolocation still doesn't work for me in 26.0a2 (2013-10-15) on Win7 x64. Does work in Beta and Nightly.
(In reply to Rob Crowther from comment #26) > Should this be fixed in Aurora now? Geolocation still doesn't work for me > in 26.0a2 (2013-10-15) on Win7 x64. Does work in Beta and Nightly. Try again. Works fine to me on 26.0a2 (2013-10-16)
(In reply to Paul Silaghi, QA [:pauly] from comment #27) > Try again. Works fine to me on 26.0a2 (2013-10-16) Nope. Sits there saying "Please wait some seconds. Determining your location..." but never updates, doesn't even ask if the site should be allowed to access my location. I created a clean profile this morning to confirm it wasn't some setting. Beta and nightly both work on the same machine.
Rob, please go to about:support and confirm that you are using Firefox Aurora 26.0a2 2013-10-16 or later.
That information doesn't look to be in about:support, however if I got to Help -> About Aurora it (currently) says 26.0a2 (2013-10-16).
(In reply to Rob Crowther from comment #30) > That information doesn't look to be in about:support, however if I got to > Help -> About Aurora it (currently) says 26.0a2 (2013-10-16). We've tested that version and it works for us. It's possible there is some edge-case you are hitting which we didn't account for. If you figure out what's causing this for you can you please open a new bug report?
How can I go about figuring out what the issue is? Nothing is logged in the console.
(In reply to Rob Crowther from comment #32) > How can I go about figuring out what the issue is? Nothing is logged in the > console. Sorry, I'm not familiar enough with Geolocation to advise you here. Perhaps someone else on this bug can help.
I've copied the same install on to a Windows Vista 32bit VM and it works fine. I only have the issue on my Windows 7 64bit desktop.
(In reply to Rob Crowther from comment #34) > I only have the issue on my Windows 7 64bit desktop. Try with Wi-fi disabled
I don't have Wi-fi on my desktop machine.
Hm, I wonder if we hit another edge case here beside the already fixed bug 923618 for OS X. Rob, please file a new bug for your issue. Thanks.
Logged bug 928898.
Yeah, i think if you don't have WiFi enabled, we are going to return an error. Probably a dup of 887860
You need to log in before you can comment on or make changes to this bug.