Closed Bug 888252 Opened 13 years ago Closed 13 years ago

Geolocation position is not displayed on Nightly

Categories

(Core :: DOM: Geolocation, defect)

24 Branch
defect
Not set
normal

Tracking

()

VERIFIED FIXED
Tracking Status
firefox23 --- unaffected
firefox24 + verified
firefox25 + verified

People

(Reporter: AndreeaMatei, Assigned: dougt)

References

()

Details

(Keywords: regression)

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.
Blocks: 758187
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
Blocks: 882485
No longer blocks: 758187
Version: 25 Branch → 24 Branch
Assignee: nobody → doug.turner
WFM, windows + mac
Status: NEW → RESOLVED
Closed: 13 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?
Status: RESOLVED → REOPENED
Resolution: WORKSFORME → ---
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?
Flags: needinfo?(catlee)
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 ;)
Flags: needinfo?(catlee)
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!
Status: ASSIGNED → RESOLVED
Closed: 13 years ago → 13 years ago
Resolution: --- → FIXED
Keywords: verifyme
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?
Flags: needinfo?(andreea.matei)
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.
Flags: needinfo?(andreea.matei)
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.
Blocks: 923618
Filed bug 923618 for the remaining issues. Marking this one verified.
Status: RESOLVED → VERIFIED
Keywords: verifyme
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
or enabled
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.