Closed Bug 888252 Opened 7 years ago Closed 7 years ago

Geolocation position is not displayed on Nightly

Categories

(Core :: DOM: Geolocation, defect)

24 Branch
defect
Not set

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: 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?
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.
Blocks: 883233
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)
No longer blocks: 883233
Depends on: 883233
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: 7 years ago7 years ago
Resolution: --- → FIXED
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.